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

[Serge Pavlov via Phabricator via llvm-commits]

sepavloff added a comment.

In D143074#4110459 <https://reviews.llvm.org/D143074#4110459>, @spatel wrote:

> 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.

We don't know how support of SNaN is important and how large is performance gain due to dropping it. The safe solution in this case is to support both strategies and let user to choose the needed.

>> 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.

According to the proposed wording SNaNs will be supported with strict exception handling only. It is not natural to couple SNaN support with FP environment because these are orthogonal things. To keep the property `SNaN + 0.0 -> QNaN` access to rounding mode or status flags is not needed, so it can be available in default environment also. Strict exception behavior is associated with substantial performance drop and it can be inappropriate for users that use them.


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

https://reviews.llvm.org/D143074