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

[Kevin P. Neal via Phabricator via llvm-commits]

kpn 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?

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.

> Also, "status flags may be set to arbitrary values" by what exactly? Is it assuming that the initial state is arbitrary? If it's talking about operations, it certainly doesn't imply that they are side effect-free. Quite the opposite, since it implies that operations do in fact have side effects and can do arbitrary things to the status flags, and therefore can never be reordered. This is worse than the normal semantics, since those at least ensure that operations can be freely reordered as long as the reordering doesn't cross a read or clear of the status flags.

There aren't going to be any reads of the status flags because in the default environment we define them to never be observed by the program. So no reads, and we can reorder as we wish. At program start all flags are lowered, and they may be changed during the execution of the program but the program won't see it.

The default environment is what we assume when "FENV_ACCESS OFF" (or similar with compiler flags and maybe other pragmas), and we support accessing the floating point environment and possibly enabling Unix signals when using "FENV_ACCESS ON". The constrained floating point intrinsics are for the latter case. We try to get sNaN handling correct with the constrained intrinsics, and those are described in a different part of the document. The constrained intrinsics are still marked experimental.

> In order to actually be side effect-free you need to declare that status flags don't exist, are treated as nonexistent, or that any attempt to read the status flags may return arbitrary values. As soon as operations are declared to interact (or not interact) with status flags, you have the problem of making sure they are (or aren't) modified by them.

If you are going to be interacting with the status flags then you need to be using the constrained floating point intrinsics where you are allowed to access the FP environment and to be in an alternate floating point environment. With the constrained intrinsics you are allowed to observe the FP status flags. No constrained intrinsics, no observing the status flags. Period.


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

https://reviews.llvm.org/D143074