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

Serge Pavlov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 30 07:57:58 PDT 2021


sepavloff added a comment.

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



More information about the llvm-commits mailing list