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

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a subscriber: aqjune.
lebedev.ri added a comment.

CC @nlopes / @aqjune

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

> In D106362#3033377 <https://reviews.llvm.org/D106362#3033377>, @lebedev.ri wrote:
>
>> In D106362#3033346 <https://reviews.llvm.org/D106362#3033346>, @sepavloff wrote:
>>
>>> In D106362#3032900 <https://reviews.llvm.org/D106362#3032900>, @lebedev.ri wrote:
>>>
>>>> `fadd X, -0 ==> X` is *NOT* a miscompile, at least given the current LLVM IR semantics: https://alive2.llvm.org/ce/z/TuTiSQ
>>>> I would personally strongly suggest to not reason about semantics via hand-waving, but to actually model them in alive2, if it isn't already.
>>>> Honestly, i'm quite worried that this is repeating the same approach as in isnan threads.
>>>> Some might interpret it as being dismissive/intentionally ignoring documented semantics.
>>>
>>> Here is the sample program: https://godbolt.org/z/ssYs6ez91
>>> Hardware converts `SNaN + 0` into QNaN.
>>
>> Could you please write a little longer arguments?
>> Your point being? Pick one of:
>>
>> 1. the optimization is incorrect as per the llvm langref
>> 2. the optimization is correct as per the llvm langref, which is itself incorrect
>> 3. ???
>>
>> Which one is it?
>
> This optimization is incorrect because it violates IEEE-754, which states (6.2):
>
>   Under default exception handling, any operation signaling an invalid operation exception and for which a
>   floating-point result is to be delivered shall deliver a quiet NaN.
>
> As a result it is inconsistent with the main hardware implementations, including at least X86, RISC-V and ARM. If it matters I can provide the exact references.
>
> 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.


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

https://reviews.llvm.org/D106362