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

[Ralf via Phabricator via llvm-commits]

RalfJung added a comment.

> My worry is: Does having such an indeterminate output value, combined with other optimization passes, trigger unbounded UB from the system as-a-whole? E.g., because we can duplicate and coalesce FP math instructions, and make a different optimization decision for each duplicated instance separately, a single fadd with an sNaN input could appear to be a qNaN to some of its uses and an sNaN for others. Which then as discussed changes the results of finite values from FP computations too. Could that cause problems in downstream optimization passes?

Note that this is already a concern even without the special sNaN handling: the exact qNaN being produced by 0.0/0.0 is non-deterministic, and can differ depending on which optimizations are applied.  (See for instance this Rust issue <https://github.com/rust-lang/rust/issues/55131>.)

So it is already the case that optimizations may not duplicate FP math instructions (unless they can prove that the result is not a NaN).  Coalescing is fine though.


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

https://reviews.llvm.org/D143074