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

On Mon, Sep 20, 2021 at 1:04 PM Mehdi AMINI via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On Mon, Sep 20, 2021 at 1:23 AM Serge Pavlov <sepavloff at gmail.com>
wrote:
>>
>> On Fri, Sep 17, 2021 at 11:17 PM Mehdi AMINI <joker.eph at
gmail.com> wrote:
>>>
>>> On Thu, Sep 16, 2021 at 11:19 PM Serge Pavlov <sepavloff at
gmail.com> wrote:
>> Also if we agree that NaNs can appear in the code compiled with
-ffinite-math-only, there must be a way to check if a number is a NaN.
>
>
> 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. Assuming
that all values are the result of floating-point arithmetic is a
faulty assumption.

~Aaron

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.

HTH,
–Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210920/c14edfc8/attachment.html>

On Mon, Sep 20, 2021 at 10:11 AM Aaron Ballman <aaron at aaronballman.com>
wrote:
>
> On Mon, Sep 20, 2021 at 1:04 PM Mehdi AMINI via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > On Mon, Sep 20, 2021 at 1:23 AM Serge Pavlov <sepavloff at
gmail.com> wrote:
> >>
> >> On Fri, Sep 17, 2021 at 11:17 PM Mehdi AMINI <joker.eph at
gmail.com> wrote:
> >>>
> >>> On Thu, Sep 16, 2021 at 11:19 PM Serge Pavlov <sepavloff at
gmail.com> wrote:
> >> Also if we agree that NaNs can appear in the code compiled with
-ffinite-math-only, there must be a way to check if a number is a NaN.
> >
> >
> > 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. Assuming
> that all values are the result of floating-point arithmetic is a
> faulty assumption.
Right, but having to manage the fact that `x + 0. -> x` would become a
potential pessimization for the optimizer is quite disturbing to me.

-- 
Mehdi