[LangRef] nnan and ninf produce poison.

[efriedma]

Summary

Clarify that violating nnan and ninf can lead to undefined behavior. This allows more aggressive optimizations based on those assumptions.

[nlopes]

docs/LangRef.rst

2347 ↗

(On Diff #150579)

This is precisely the definition of undef: an arbitrary value that may yield a different value each time it's used. But the intention was to avoid undef and poison.
I'm not familiar enough with floats to make any concrete suggestion; I'm just type checking.

[efriedma]

Clarify that the value produced isn't undef. (It's more like freeze(undef).)

[spatel]

This reads clearer to me by avoiding the potential to confuse with UB. Should the same blurb apply to nsz with -0.0?

[hfinkel]

I don't think this is right. Saying the result is undefined seems like what we intend. We might choose, as an implementation technique, to limit how we take advantage of that undefinedness in certain cases, but the violating the constraint still produces logical inconsistencies that can transfer to other parts of the code, and in general, turn into any other kind of undefined behavior (depending on the structure of the code).

[efriedma]

It has to be one of undefined behavior, poison, undef, or an unspecified value as described here; there is no other way for something to be "undefined" in LLVM IR, unless you're proposing to introduce a new form of undefined-ness specifically for nnan/ninf.

[sanjoy]

I think we should have these produce poison -- if we have them produce undef we'll have the same kinds of problems as we have with regular undef.

nnan and ninf affect fcmp

Only if the fcmp is marked with nnan or ninf right?

[efriedma]

Only if the fcmp is marked with nnan or ninf right?

Yes, but it's inconvenient in C because fast-math flags work on a per-file basis.

---

If the consensus is that we need to produce poison for nnan/ninf instead of an unspecified value, I can change that. I guess it allows more aggressive fcmp transforms in some cases?

[efriedma]

Okay, switched to poison.

[efriedma]

Ping

[hfinkel]

LGTM

llvm/trunk/docs/LangRef.rst

 LLVM IR floating-point operations (:ref:`fadd <i_fadd>`,
 :ref:`fsub <i_fsub>`, :ref:`fmul <i_fmul>`, :ref:`fdiv <i_fdiv>`,
 :ref:`frem <i_frem>`, :ref:`fcmp <i_fcmp>`) and :ref:`call <i_call>`
 may use the following flags to enable otherwise unsafe
 floating-point transformations.
 
 ``nnan``
    No NaNs - Allow optimizations to assume the arguments and result are not
-   NaN. Such optimizations are required to retain defined behavior over
-   NaNs, but the value of the result is undefined.
+   NaN. If an argument is a nan, or the result would be a nan, it produces
+   a :ref:`poison value <poisonvalues>` instead.
 
 ``ninf``
    No Infs - Allow optimizations to assume the arguments and result are not
-   +/-Inf. Such optimizations are required to retain defined behavior over
-   +/-Inf, but the value of the result is undefined.
+   +/-Inf. If an argument is +/-Inf, or the result would be +/-Inf, it
+   produces a :ref:`poison value <poisonvalues>` instead.
 
 ``nsz``
    No Signed Zeros - Allow optimizations to treat the sign of a zero
    argument or result as insignificant.
 
 ``arcp``
    Allow Reciprocal - Allow optimizations to use the reciprocal of an
    argument rather than perform division.