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

[Arthur O'Dwyer via llvm-dev]

On Mon, Sep 13, 2021 at 10:09 AM Krzysztof Parzyszek via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> *From:* Serge Pavlov <sepavloff at gmail.com>
>> `isnan` does not begin with an underscore, so it is not a reserved
>> identifier. Why is its redefinition an UB?
>
> The standard says so, but I can’t find the corresponding passage in the
> draft...
>
>
I don't know about C, but in C++ redefining any library name as a macro is
forbidden by
https://eel.is/c++draft/reserved.names#macro.names-1

Btw, I don't think this thread has paid enough attention to Richard Smith's
suggestion: that in fast-math mode, the implementation should
- treat all quiet NaNs as if they are signaling NaNs
- treat all "signals" as if they are UB *produce an unspecified value*
So, any floating-point operations that IEEE754 guarantees will work
silently even on signaling NaNs, must continue to work on any kind of NaN
in fast-math mode. But any operation that is allowed to signal, is
therefore allowed to give wrong results if you feed it any kind of NaN in
fast-math mode. In this model, we don't talk about specific mathematical
identities like "x+0 == x". Instead, we say "If !isnan(x), then
computationally x+0 == x; and if isnan(x), then x+0 is allowed to signal
and therefore in fast-math mode we can make its result come out to any
value we like. Therefore, if the optimizer sometimes wants to pretend that
QNAN + 0 == QNAN, that's perfectly acceptable."

Notice that you cannot make "signaling" into actual UB; you must make
it *produce
an unspecified value*. If you make it UB, then the compiler will happily
optimize

    {
        if (!isnan(someGlobal)) puts("it's not nan");  // #1
        double x = someGlobal;
        x += 1;  // This is a signaling operation
    }

into

    {
        puts("it's not nan");  // because if it were NaN on line #1, then
either we'd hit that signaling operation, or we'd have a data race
    }

But if you just make "signaling" operations produce unspecified values when
given NaN, then I think everything works fine and you end up with behavior
that's pretty darn close to what Serge is advocating for with his "New"
behavior.

my $.02,
–Arthur

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210913/6230cec8/attachment.html>