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

[James Y Knight via llvm-dev]

On Thu, Sep 9, 2021 at 11:02 AM Sanjay Patel <spatel at rotateright.com> wrote:

> Not sure which way to go, but I agree that we need to improve the
> docs/user experience either way.
> Let's try to iron this out with an example (this is based on
> https://llvm.org/PR51775 ):
>
> #include <math.h>
> #include <stdlib.h>
> int main() {
>     const double d = strtod("1E+1000000", NULL);
>

This should be covered by the "general function call" rule, is therefore
unaffected by -ffinite-math-only, and may validly return inf.

    return d == HUGE_VAL;
>

For this comparison, however, the compiler can assume its operands are
always finite. Thus, this comparison results in a poison value (in LLVM IR
terminology).

What should this program return when compiled with -ffinite-math-only?
> Should this trigger a clang warning?
> https://godbolt.org/z/MY73Tf3ee
>

We could indeed emit a diagnostic (when -ffinite-math-only is in effect) to
let you know that you are doing something guaranteed to be incorrect, by
using a manifest constant INF, where you promised that you would not.


> The proposed documentation text isn't clear to me. Should clang apply
> "nnan ninf" to the IR call for "strtod"?
>
"strtod" is not in the enumerated list of functions where we would block
> fast-math-flags, but it is a standard lib call, so "nnan ninf" would seem
> to apply...but we also don't want "-ffinite-math-only" to alter the ability
> to return an INF from a "general function call"?
>


The strtod function should be allowed to return inf/nan. There's two ways
we could accomplish that:
1. We could specify in LLVM that nnan/ninf are meaningless to most function
calls. In this case, Clang may continue emitting it everywhere, as is done
today, including on strtod, but it would have no impact.
2. We could specify that clang should not emit nnan/ninf except on certain
calls. In this case, Clang would not emit it on strtod.

I haven't thought about which option would be better. I've been trying to
discuss the desired C-facing semantics first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210909/98898466/attachment.html>