[PATCH] D143074: [LangRef] improve documentation of SNaN in the default FP environment

Thu Feb 9 10:31:04 PST 2023

spatel added a comment.

In D143074#4114288 <https://reviews.llvm.org/D143074#4114288>, @Muon wrote:

> Hold on, that still says that operations //assume// that all NaNs are quiet. Doesn't that mean that passing a signaling NaN to an operation is potentially undefined behavior? Can we instead say that math operations treat all NaNs as if they were quiet NaNs? Does that run into issues with pow() and friends?

Passing SNaN is not undefined behavior. Either it's going to pass through the optimizer undetected, or it's going to be noticed and be optimized as if it were a QNaN. It seems similar to our description of the "nsz" fast-math-flag:
"No Signed Zeros - Allow optimizations to treat the sign of a zero argument or zero result as insignificant. This does not imply that -0.0 is poison and/or guaranteed to not exist in the operation."

C2X draft N3047 says this in "F.2.1":
"This annex does not require the full support for signaling NaNs specified in IEC 60559. This annex uses the term NaN, unless explicitly qualified, to denote quiet NaNs. Where specification of signaling NaNs is not provided, the behavior of signaling NaNs is implementation-defined (either treated as an IEC 60559 quiet NaN or treated as an IEC 60559 signaling NaN). 438)
438)Since NaNs created by IEC 60559 arithmetic operations are always quiet, quiet NaNs (along with infinities) are sufficient for closure of the arithmetic."

Is there something we can adapt from either of those to make the text clearer?

In D143074#4115297 <https://reviews.llvm.org/D143074#4115297>, @kpn wrote:

> How many of these sNaN vs qNaN cases that matter are there? I've seen pow() mentioned in this ticket. What are the other cases?
>
> Maybe a sentence or two that states we may treat sNaN and qNaN differently if required by a standards document but otherwise don't? Except we probably don't right now and shouldn't promise we do or will.

We do not treat them differently in any optimization that I know of, and we don't want to start. We want to operate as we are currently - that lines up with the C spec quoted above.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143074/new/

https://reviews.llvm.org/D143074