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

[Kevin P. Neal via Phabricator via llvm-commits]

kpn added a comment.

>>> 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.
>
> This is peculiarities of IEEE-754 language. `Exception handling` in this context is what to do if exceptional situation occurs. In 7.1 there is a description of the `default exception handling`:
>
>   This clause also specifies default non-stop exception handling for exception signals, which is to deliver a
>   default result, continue execution, and raise the corresponding status flag (except in the case of exact
>   underflow, see 7.5).
>
> This is exactly the way the exceptions are handled in the default FP environment. Exception must be handled in some way because hardware always signals them if exceptional situation occurs.

I agree with @sepavloff's interpretation of IEEE-754. It's a bit jarring switching between -754 and the LangRef or Unix because they use the same words but with different meanings.

However, my understanding is that strict IEEE-754 compliance is _not_ a goal of the LLVM project. And having different behavior than the hardware in the case of NaN handling in the non-trapping case is generally accepted because of the large performance boost in total. LLVM implements its own IR language and NaN handling (non-trapping case) is one of those times where the IR language does not promise to behave like the hardware.

I'll do what @spatel asked and narrow the changes down to get this moving.


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

https://reviews.llvm.org/D106362