[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:35 PM Mehdi AMINI <joker.eph at gmail.com> wrote:
>
> 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.

Eh, this is in an "ignore the standard" compiler mode, so all of it is
quite disturbing to me. :-D But more seriously, I would rather we err
on the side of caution when deciding which code the user explicitly
wrote that can be removed by the optimizer. When my code goes slow, I
can profile it to see what's causing that and react accordingly if I
care. When the optimizer removes some error handling code I have, I am
100% reliant on my testing infrastructure catching that before my
users do, and testing code is sometimes run in debug mode for a
variety of reasons and not everyone writes fantastic testing code that
covers all of their error cases. To me, being conserative is the less
user-hostile approach in this case.

~Aaron

>
> --
> Mehdi