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

[Arthur O'Dwyer via llvm-dev]

On Tue, Sep 14, 2021 at 9:22 AM Serge Pavlov via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Tue, Sep 14, 2021 at 8:21 PM Krzysztof Parzyszek <kparzysz at quicinc.com>
> wrote:
>
>> If `has_nan` returns "true", it means that the explanation "there are no
>> NaNs" does not work anymore and something more complex is needed to explain
>> the effect of the option. In this case it is difficult to say that this
>> approach is "intuitively clear".
>>
>>
>>
>> If your program has “x = *p”, it means that at this point p is never a
>> null pointer.  Does this imply that the type of p can no longer represent a
>> null pointer?
>>
>
> Good example! If you use integer division `r = a / b`, you promise that
> `b` is not zero. It however does not mean  that preceding check `b == 0`
> may be optimized to `false`.
>

In C and C++, it actually *does* mean that, although of the compilers I
just tested on Godbolt, only MSVC seems to take advantage of that
permission.
https://godbolt.org/z/11ss5T7e8

The question of whether it is acceptable to treat as equivalent the
statements "p is known to be dereferenced in all successors of B" and "p is
known to be non-null in B," was discussed extensively about 20 years ago,
and then again 12 years ago when it bit someone in the Linux kernel:
https://www.gnu.org/software/gcc/news/null.html
https://lwn.net/Articles/342330/
https://lwn.net/Articles/342420/
https://qinsb.blogspot.com/2018/03/ub-will-delete-your-null-checks.html

On Mon, Sep 13, 2021 at 10:28 PM Arthur O'Dwyer <arthur.j.odwyer at gmail.com>
>> wrote:
>>
>> Btw, I don't think this thread has paid enough attention to Richard
>> Smith's suggestion:
>>
>> I can only subscribe to James Y Knight's opinion. Indeed, it can be a
>> good criterion of which operations should work in finite-math-only mode and
>> which can not work. The only thing which I worry about is the possibility
>> of checking the operation result for infinity (and nan for symmetry). But
>> the suggested criterion is formulated in terms of arguments, not results,
>> so it must allow such checks.
>>
>
*What* is the opinion to which you subscribe?

Anyway, Richard's "quiet is signaling and signals are unspecified values"
is really the only way out of the difficulty, as far as compiler people are
concerned. You two (Serge and Krzysztof) can keep talking past each other
at the application level, but the compiler people are going to have to do
*something* in the code eventually, and that *something* is going to have
to be expressed in terms similar to what Richard and I have been saying,
because these are the terms that the compiler understands.

Thanks,
Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210914/4e239a5a/attachment.html>