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

[Eli Friedman via Phabricator via llvm-commits]

efriedma 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?

We need to be a little careful with operations that produce non-deterministic results, sure; in particular, we can't rematerialize/LoopSink/etc. them, and certain peepholes aren't legal if a value has multiple uses.  (A simple example of such an instruction is "freeze poison".)  This is something we have to deal with anyway for floating-point ops, though; fast-math is defined to be non-deterministic.


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

https://reviews.llvm.org/D143074