[PATCH] D106362: [FPEnv][InstSimplify] Enable more folds for constrained fadd

[Sanjay Patel via Phabricator via llvm-commits]

spatel added a comment.

In D106362#3033555 <https://reviews.llvm.org/D106362#3033555>, @sepavloff wrote:

>>> Here is the sample program: https://godbolt.org/z/ssYs6ez91
>>> Hardware converts `SNaN + 0` into QNaN.

This is cherry-picking the example to try to prove your point; gcc does not behave as you are suggesting in general. Here is a counter-example based on the first transform (fadd X, -0.0) affected by this patch:
https://godbolt.org/z/qj9Meavnd

> As for llvm langref, I think the following statement is cited here: https://llvm.org/docs/LangRef.html#floating-point-environment:
>
>   The default LLVM floating-point environment assumes that floating-point instructions do not have side effects. Results assume the round-to-nearest rounding mode. No floating-point exception state is maintained in this environment. Therefore, there is no attempt to create or preserve invalid operation (SNaN) or division-by-zero exceptions.
>
> This sentence is about **exceptions** but not the results of operations. So actually nothing in the langref justifies this transformation.

The wording could be made more explicit, but as I suggested in my comment from Aug 6 in this review: the default LLVM FP env ignores exceptions, so citing the IEEE-754 clause that begins with "under default exception handling" to describe SNAN->QNAN behavior is not applicable.

But this has gone out-of-bounds for this patch review - this was just trying to nail down the behavior in a subset of a strict FP env. Please start an llvm-dev discussion if you want to change the LangRef to formalize the behavior you are proposing for default FP.

@kpn - might be worth re-starting this patch as "X + -0.0" only, so we can make progress?


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

https://reviews.llvm.org/D106362