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

[Ralf via Phabricator via llvm-commits]

RalfJung added a comment.

> Then, LLVM is broken on old MIPS. There's just no way it's okay to spuriously introduce sNaNs when the original program didn't contain sNaNs in the first place. It results in incorrect results, without the original user code breaking any assumptions.

I think I am trying to understand why this is the case. For my own use of floating points, until fairly recently I didn't even know about the sNaN vs qNaN distinction. Most programmers won't know, and they won't care. Maybe it is reasonable to expect programmers that do care to pass a strictfp flag?

OTOH, they might be very surprised if `pow(x, 0.0)` can return NaN despite the docs saying it won't... so that cursed behavior of `pow` might be a forcing function for ensuring LLVM will never introduce new sNaN.

> What about saying that for every non-bit-copy fp operation LLVM may arbitrarily treat any input NaNs as if they are quiet NaNs and any output NaNs have arbitrary quietness?

That would give LLVM license to introduce sNaN intro programs that don't originally have any sNaN. Whether that is okay seems to be the main remaining contentious point in this discussion.

So the alternative is to say that if any input is an sNaN, then output NaN have arbitrary quietness, but if there are no sNaN inputs then all output NaN will be quiet.


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

https://reviews.llvm.org/D143074