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

[Kevin P. Neal via Phabricator via llvm-commits]

kpn added a comment.

In D143074#4112184 <https://reviews.llvm.org/D143074#4112184>, @Muon wrote:

> In D143074#4110459 <https://reviews.llvm.org/D143074#4110459>, @spatel wrote:
>
>> 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.
>
> Although I am uncertain about the consequences of changing LLVM's defaults, I would like to point out that there may not actually be a performance impact to handling signaling NaNs correctly. Replacing `x * 1.0` (and the like) with `x` **is** sound whenever the only uses of `x` are in quieting floating-point operations (that is, +, -, *, /, fma, rem, sqrt, but not bitwise ops such as negate, abs or copySign). It would pretty much only affect cases where someone was just performing an isolated multiplication by 1 and returning that. (Such as, say, someone trying to quiet a possible-signaling value.)

That's a project that nobody is working on, though, and it would require widespread work in passes like InstSimplify, InstCombine, and others to add the necessary analysis to detect when it is safe and when it is not. There's also the issue that even if it is safe to make the transform, subsequent optimizations that aren't aware the transform happened might make the transform unsafe after the fact.


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

https://reviews.llvm.org/D143074