[clang] [llvm] Option to control signaling NaN support (PR #193055)

[Serge Pavlov via cfe-commits]

================
@@ -2574,6 +2574,16 @@ For example:
 ``sanitize_alloc_token``
     This attribute indicates that implicit allocation token instrumentation
     is enabled for this function.
+``signaling_nans``
+    If a function has this attribute, a signaling NaN (sNaN) is assumed to be
+    treated according to IEEE 754 rules. That is, arithmetic operations never
+    return an sNaN, and the ``Invalid``  exception  is raised if an operand of
+    such an operation is an sNaN. If this attribute is absent, an sNaN is assumed
+    to be treated identically to a quiet NaN: it can be produced by an operation
----------------
spavloff wrote:

There is no disagreement with the cited section, which specifies both varuiants:

> The quiet bit is set and the payload is copied from any input operand that is a NaN. (“Quieting NaN propagation” case)
>
> The quiet bit and payload are copied from any input operand that is a NaN. (“Unchanged NaN propagation” case)

It does not specify which is used in the particular case, introducing the attribute `signaling_snan` resolves this indeterminism.

> Floating-point math operations are allowed to treat all NaNs as if they were quiet NaNs. For example, “pow(1.0, SNaN)” may be simplified to 1.0.

As I understand, this statement is about math operations, where such interpretation is natural, anyway, sNaNs are NaNs. Arithmetic operations do not obey this statement, instead "Quieting/Unchanged NaN propagation" is used.

> For the wording about throwing / exceptions, I think the way to do this is to explicitly say that "if strictfp is also enabled, then"

I will change documentation accordingly.

https://github.com/llvm/llvm-project/pull/193055