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

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>

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>

On Tue, Sep 14, 2021 at 11:15 AM Arthur O'Dwyer via llvm-dev
<llvm-dev at lists.llvm.org> 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
>
> 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.
Hopefully the clarified semantics can be coordinated between and
implemented in a consistent manner in both LLVM and GCC.

Thanks, David

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.

I don’t know why you’re saying “at the application level”.  My concerns are
motivated by what the compiler is supposed to do.  I don’t think that the
consequences of “arithmetic operations don’t produce NaNs” are fully understood,
and are likely not completely intuitive either.  We may end up having
discussions as to whether we should optimize x+0 to x or not, because “x+0”
carries the information that it won’t result in a NaN, while “x” alone doesn’t. 
This is one case that comes to mind and I’m concerned that there are many others
that we aren’t aware of yet.

--
Krzysztof Parzyszek  kparzysz at quicinc.com<mailto:kparzysz at
quicinc.com>   AI tools development

From: Arthur O'Dwyer <arthur.j.odwyer at gmail.com>
Sent: Tuesday, September 14, 2021 10:15 AM
To: Serge Pavlov <sepavloff at gmail.com>
Cc: Krzysztof Parzyszek <kparzysz at quicinc.com>; llvm-dev at
lists.llvm.org; cfe-dev at lists.llvm.org
Subject: Re: [cfe-dev] [llvm-dev] Should isnan be optimized out in fast-math
mode?


WARNING: This email originated from outside of Qualcomm. Please be wary of any
links or attachments, and do not enable macros.
On Tue, Sep 14, 2021 at 9:22 AM Serge Pavlov via cfe-dev <cfe-dev at
lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
On Tue, Sep 14, 2021 at 8:21 PM Krzysztof Parzyszek <kparzysz at
quicinc.com<mailto: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<mailto: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/2fb841b5/attachment-0001.html>