[PATCH] D143074: [LangRef] improve documentation of SNaN in the default FP environment

Tue Feb 7 08:36:45 PST 2023

spatel added a comment.

In D143074#4108919 <https://reviews.llvm.org/D143074#4108919>, @sepavloff wrote:

> In D143074#4108036 <https://reviews.llvm.org/D143074#4108036>, @jyknight wrote:
>
>>> The property of SNaN like SNan + 0.0 -> QNaN is not related to exceptions and must be preserved in default environment also.
>>
>> Neither GCC nor Clang have considered sNaN-related semantics important to provide by default thus far, and I don't think we ought to start now, either.

Agreed - we're not changing the default LLVM behavior with this patch, and I have not heard any reasons why we should. IEEE-754-compliant SNaN handling isn't important enough to the majority of FP users to justify FP performance regressions.

> GCC has option `-fsignaling-nans`, which may be used to turn on standard treatment of SNaNs. Clang does not have similar option, now the only way to handle SNaNs in the standard way is to turn on exception handling, which is not suitable in some cases. LLVM as a low-level component must support SNaN on an opt-in basis, but request for such support must be more selective. Anyway SNaN treatment is nor a part of strict exception handling semantics.

I think every combination of IEEE-754-(non-)compliance is covered by existing Clang flags at this point:
https://clang.llvm.org/docs/UsersManual.html#controlling-floating-point-behavior

If `-fsignaling-nans` is important enough, it could be added as an alias of some combo of those flags. If the optimizer is not behaving as specified by those flags, that's a bug. Here's a bug fix proposal:
https://reviews.llvm.org/D143505

Here's a test program/playground for messing with the optimization settings:
https://godbolt.org/z/EWrKdYx1W

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143074/new/

https://reviews.llvm.org/D143074