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

Fundamentally, the question Serge asked has nothing to do with the concerns of
“compiler people”, and everything to do with the user facing behavior of the
compiler. Any talk of how the behavior should be implemented is (in my opinion)
off topic until we settle the question of “should the compiler guarantee, as a
special case, that isnan(x) will not be optimized out”. This is a Yes-or-No
question, and the explanation for the answer needs to be able to be concisely
described in the docs without the use of compiler jargon that Joe GameDev and
Tom MLScientist probably don’t understand. I have stated my opinion, and am
reluctant to wade into this argument again, but I think it’s important that we
understand the issue at hand.

There are two productive outcomes of this question that I can see:


  1.  The answer is No. In this case, we just need a small doc fix
  2.  The answer is Yes. Only in this case do we actually need to modify the
implementation

Let’s not put the cart before the horse. The “compiler people” don’t necessarily
have to do anything.

Thanks,
   Chris Tetreault

From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Krzysztof
Parzyszek via cfe-dev
Sent: Tuesday, September 14, 2021 3:28 PM
To: Arthur O'Dwyer <arthur.j.odwyer at gmail.com>; Serge Pavlov
<sepavloff at gmail.com>
Cc: 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.
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<mailto:arthur.j.odwyer at gmail.com>>
Sent: Tuesday, September 14, 2021 10:15 AM
To: Serge Pavlov <sepavloff at gmail.com<mailto:sepavloff at
gmail.com>>
Cc: Krzysztof Parzyszek <kparzysz at quicinc.com<mailto:kparzysz at
quicinc.com>>; llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>; cfe-dev at lists.llvm.org<mailto: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/20210915/cb9687c2/attachment.html>

On Wed, Sep 15, 2021 at 12:42 PM Chris Tetreault <ctetreau at quicinc.com>
wrote:
> Fundamentally, the question Serge asked has nothing to do with the
> concerns of “compiler people”, and everything to do with the user facing
> behavior of the compiler. Any talk of how the behavior should be
> implemented is (in my opinion) off topic until we settle the question of
> “should the compiler guarantee, as a special case, that isnan(x) will not
> be optimized out”. This is a Yes-or-No question [...]
>
That's a good illustration of what I meant by "application level."
The
user who asks "Will my call to isnan() be 'optimized out'?"
doesn't really
have any sense of what's going on at the compiler level. The compiler
person can say, "Yes, of course *some* calls to `isnan` can be
eliminated"
and show them all kinds of examples:

    void one(double d) { (void)isnan(d); puts("hello world"); }
    void two(double d) { d = 2.0; if (isnan(d)) puts("this branch is
dead"); }
    void three(double d) { d *= 0.0; if (isnan(d)) puts("this branch is
dead only in fast-math mode"); }

but they don't really care about these examples; they care about one
specific use of isnan() somewhere deep inside their specific application.
We can't really give a Yes or No answer about that one because we can't
see
it; all we can do is try to explain the rules by which the compiler decides
whether a given transformation is OK or not, and then the application
developer has to take those rules back home and study their own code to
figure out whether the compiler will consider the transformation OK to
apply to that code.

HTH,
Arthur
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210915/a3c1e5ad/attachment.html>