[llvm-dev] [cfe-dev] Should isnan be optimized out in fast-math mode?

[Aaron Ballman via llvm-dev]

On Mon, Sep 20, 2021 at 1:15 PM Arthur O'Dwyer
<arthur.j.odwyer at gmail.com> wrote:
>
> On Mon, Sep 20, 2021 at 1:11 PM Aaron Ballman via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>>
>> On Mon, Sep 20, 2021 at 1:04 PM Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> >
>> > I'd find it unfortunate though that in a mode which specifies that the result of floating point arithmetic can't have NaN we can't constant fold isnan(x) where x is a potentially complex expression (think that x could be dead-code if not for the isnan).
>>
>> I think part of my concern is with the "result of floating point
>> arithmetic can't have NaN" statement. I consider this case:
>>
>> if (isnan(foo / bar)) {}
>>
>> to be fundamentally different from this case:
>>
>> if (isnan(foo)) {}
>>
>> because the first example can never result in the if branch being
>> taken with -ffinite-math-only while the second example can.
>
>
> Mehdi's statement is consistent with your interpretation, yes.  In the first case, "foo / bar" is the result of floating-point arithmetic.  In the second case, "foo" is not the result of floating-point arithmetic — or at least, you didn't demonstrate that it was.
>
> Of course if the preceding line was
>
>     foo = foo / bar;
>     if (isnan(foo)) {}
>
> then we can constant-fold `isnan(foo)` to false, as Mehdi said, because `foo`'s value is the result of floating-point arithmetic.

Thanks! So long as we are conservative with the optimization and only
fold the call to isnan when the operand is proven to be the result of
an arithmetic expression, my concerns are lessened.

~Aaron

>
> HTH,
> –Arthur