[llvm] [LangRef] make consequences of NaN rules for pow(i) more explicit (PR #170177)

[Joshua Cranmer via llvm-commits]

================
@@ -16831,6 +16836,11 @@ trapping or setting ``errno``.
 When specified with the fast-math-flag 'afn', the result may be approximated
 using a less accurate calculation.
 
+Note that due to how :ref:`LLVM treats NaN values <floatnan>`, the special cases
----------------
jcranmer-intel wrote:

> `minimumNumber`/`maximumNumber` are exceptions from this, right? Strangely the first sentence does not acknowledge the existence of exceptions.

The first sentence of the quoted paragraph is actually about exceptions, but I elided it because exceptions aren't particularly relevant here, when we're talking about non-strictfp semantics.

Section 9.2 is just the category of libm functions I find difficult to group under a common name but fall into the general category of "computational, not-correctly rounded." The `minimumNumber`/`maximumNumber` functions fall under section 9.6, which lacks such a catch-all rule (as the functions intentionally have very different NaN behavior from one another).

> We could say something more general, like "note that if some inputs are signaling NaNs, the function may non-deterministically treat some or all of them as quiet NaNs, which can lead to non-NaN results"

This is a quick stab at wording, so take it with a grain of salt: "The `pow` function is one where replacing an sNaN with a qNaN changes the result. Due to LLVM's NaN-propagation rules [link], this means that the function result is effectively nondeterministic." (I was going to add something about `strictfp`, and then I realized that was going to just add more confusion given the current state of affairs there.)

https://github.com/llvm/llvm-project/pull/170177