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

[Serge Pavlov via llvm-dev]

On Tue, Sep 14, 2021 at 10:15 PM Arthur O'Dwyer <arthur.j.odwyer at gmail.com>
wrote:

> 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
>

But this is the *following* check, not preceding.


> 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?
>

I mean this post:

On Fri, Sep 10, 2021 at 9:29 PM James Y Knight via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Thu, Sep 9, 2021, 8:59 PM Richard Smith via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Would it be reasonable to treat operations on Inf and NaN values as UB in
>> this mode only if the same operation on a signaling NaN might signal?
>> (Approximately, that'd mean we imagine these non-finite value encodings all
>> encode sNaNs that are UB if they would signal.) That means the operations
>> that ISO 60559 defines as non-computational or quiet-computational would be
>> permitted to receive NaN and Inf as input and produce them as output, but
>> that other computational operations would not.
>>
>> Per ISO 60559, the quiet-computational operations that I think are
>> relevant to us are: copy, negate, abs, copySign, and conversions between
>> encoding (eg, bitcast). The non-computational operations that I think are
>> relevant to us are classification functions (including isNaN).
>>
>
> I'm in favor. (Perhaps unsurprisingly, as this is precisely the proposal I
> made earlier, worded slightly differently. :)
>

Sorry for the unclear statement.


> 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.
>
>
Glad to hear it. If we decide to implement Richard's approach, I will put
back the patches that implement `llvm.isnan` and continue implementing
other similar intrinsics. Clang needs missing `__builtin_*` intrinsics,
they should be mapped into the new llvm intrinsics. Not sure when the
user's manual should be updated, now or after the desired behavior will be
implemented.


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