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

[Ralf Jung 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
----------------
RalfJung wrote:

> IEEE 754-2019 has the general catch-all rule for operations in section 9.2

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

> Maybe "note this operation can non-deterministically return a non-NaN result given an SNaN input"? Not really attached to the exact wording.

Well, this can only happen in very specific cases. I take it you're not happy with mentioning `0^x`/`x^1`? 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". The rest follows as an emergent property. However, [quoting @nikic](https://discourse.llvm.org/t/rfc-a-consistent-set-of-semantics-for-the-floating-point-minimum-and-maximum-operations/89006/3)
> Because LLVM’s (non-strictfp) NaN semantics allow treating sNaN as qNaN, and allow the omission of canonicalizing operations that would turn sNaN into qNaN, it is not actually possible to guarantee a specific sNaN behavior in any sensible way. By itself, this is not a problem – this just means that the result is going to be non-deterministic. But I think this is something that needs to be explicitly acknowledged in the LangRef wording, not just treated as an emergent property.

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