[clang] [llvm] Option to control signaling NaN support (PR #193055)
Serge Pavlov via cfe-commits
cfe-commits at lists.llvm.org
Mon Apr 27 11:49:45 PDT 2026
================
@@ -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
----------------
spavloff wrote:
> I don't think it makes sense to treat targets where sNaNs don't exist the same way as targets where sNaNs exist, but we're intentionally ignoring the fact that they exist.
Why we ignore such targets? Many of them are from the important class of ML and graphic cores. We can support them.
> That's a significant difference in hardware behavior that I don't think we can paper over.
Is it really so significant? From viewpoint of the compiler, only small cases, like add/subtract 0.0, multiply/divive 1.0 and max/min operations would exhibit difference if signaling nans are supported.
Fot the case of strictfp function, where exceptions are important, the difference is larger, but we currently don't have such transformations anyway.
https://github.com/llvm/llvm-project/pull/193055
More information about the cfe-commits
mailing list