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

Sat Feb 4 17:38:29 PST 2023

Muon added a comment.

In D143074#4104239 <https://reviews.llvm.org/D143074#4104239>, @RalfJung wrote:

> This is not about assuming anything though (whose job would it be to satisfy these assumptions?), it is about *defining* what the behavior of these operations in LLVM IR (in the Abstract Machine) is.

I was just trying to use the same language as the original text. I'm guessing it really means that "these assumptions are made by optimizations". Regarding what LLVM actually does, I think it would be more accurate to say that floating-point IR instructions are lowered to the closest target-specific counterpart, but optimizations assume that the lowering conforms to IEEE 754 semantics (except as mentioned). Remember that LLVM doesn't put in the extra work to actually make the x87 produce conformant results for `float` or `double`, or to ensure that subnormals work on FPUs that don't implement them. (In any case, IR semantics don't seem to be described in a strict definition style in the rest of the LangRef.)

In D143074#4104502 <https://reviews.llvm.org/D143074#4104502>, @jyknight wrote:

> Taking `pow` in particular, the correct results are:
>
>   pow(1.0, sNaN) -> qNaN
>   pow(1.0, qNaN) -> 1.0
>   pow(sNaN, 0) -> qNaN
>   pow(qNaN, 0) -> 1.0

Only if pow follows the IEEE 754 recommendation. However, llvm.pow <https://llvm.org/docs/LangRef.html#llvm-pow-intrinsic> is defined to conform to the C standard library's semantics, which state that pow(1.0, NaN) = 1.0, for any NaN. Similarly for the rest of those intrinsics; they're just shortcuts for the C math library functions, none of which follow the IEEE 754 recommendation in that regard.

In D143074#4104506 <https://reviews.llvm.org/D143074#4104506>, @arsenm wrote:

> The snan problem is essentially the same as the question of whether denormals are flushed. We have llvm.canonicalize for stronger guarantees about flushing behavior than an arbitrary IR instruction. I think canonicalize should get a note that it musta quiet signaling nans.
>
> APFloat also assumes new IEEE signaling representation. MIPS old style nans have to be all kinds of broken but I’m not sure how much we should really care

llvm.canonicalize <https://llvm.org/docs/LangRef.html#llvm-canonicalize-intrinsic> already says "SNaNs must be quieted per the usual methods". APFloat is no doubt broken on MIPS in that regard.

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

https://reviews.llvm.org/D143074