when x is NaN in trig functions return x rather than NaN

[oscardssmith]

see #48523 for reasoning.

[topolarity]

I think this guarantee is destroyed by the LLVM optimizer anyway

From page 5 of https://arxiv.org/pdf/1603.09290.pdf:

The standard corresponds to IEEE 754-2008 but it only defines a single NaN value and does not distinguish between signalling and quiet NaNs. Thus, our implementation cannot verify whether an operation with NaN operands returns one of the input NaNs, propagating debug information encoded in the NaN, as recommended by the IEEE standard. In practice, LLVM does not attempt to preserve information in NaNs, so this limitation does not affect our ability to verify LLVM optimizations.

IMO that recommendation from the IEEE standard is silly. Although the discussion in #48523 rightly points out that payload tagging has useful applications, I don't think that extends to propagating the payload through arithmetic.

edit: But IIUC, this change is done for performance reasons, not to improve NaN propagation?

[oscardssmith]

yeah. This is (I believe) a minor performance benefit, but also makes NaN propagation a little more reliable (although LLVM still is allowed to mess with us)

[Seelengrab]

The "return x on NaN input" policy is consistent with x86, which (I think) is what we're doing in @fastmath, right? See also https://www.felixcloutier.com/x86/minps, though trigonometric equivalents in particular have.. underspecified behavior, raising floating point exceptions on SNaN, and unspecified behavior on QNaN (see https://www.felixcloutier.com/x86/fcos and https://www.felixcloutier.com/x86/fsincos)...