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

Chris Tetreault via cfe-dev cfe-dev at lists.llvm.org
Wed Sep 15 12:01:15 PDT 2021

I agree. However, we *can* answer the question “is my call to isnan(x) guaranteed not to be optimized out?” Currently, the answer is “No”. Serge is asking if we can change the answer to be “Yes” which is the application level matter that we’re discussing. It seems that Serge has done the legwork to find out if their isnan call is being optimized out, and for them it is. At this time, it’s not really important what we would do to implement the Yes behavior, other than to establish the difficulty of implementation. We want to know if we should, not if we could.

As maintainers of the compiler, it should be our goal to provide a good user experience. As it stands, it sounds like fast-math is poorly understood by users. It is within our purview to improve this UX issue by clarifying the behavior or making the behavior match user expectations.

   Chris Tetreault

From: Arthur O'Dwyer <arthur.j.odwyer at gmail.com>
Sent: Wednesday, September 15, 2021 10:58 AM
To: Chris Tetreault <ctetreau at quicinc.com>
Cc: Krzysztof Parzyszek <kparzysz at quicinc.com>; Serge Pavlov <sepavloff at gmail.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 Wed, Sep 15, 2021 at 12:42 PM Chris Tetreault <ctetreau at quicinc.com<mailto: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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210915/f75e1097/attachment.html>

More information about the cfe-dev mailing list