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

[Mehdi AMINI via cfe-dev]

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