[llvm] LangRef: Clarify llvm.minnum and llvm.maxnum about sNaN (PR #112852)

[Joshua Cranmer via llvm-commits]

================
@@ -16464,21 +16464,32 @@ type.
 
 Semantics:
 """"""""""
+Follows the IEEE-754 semantics for minNum, except that -0.0 < +0.0 for the purposes
+of this intrinsic. As for signaling NaNs, per the IEEE-754 semantics, if either operand
+is an sNaN, the result is always a qNaN. This matches the recommended behavior for the libm
+function fmin, although not all implementations have implemented these recommended behaviors.
+
+If either operand is a qNaN, returns the other non-NaN operand. Returns
+NaN only if both operands are NaN or either operand is sNaN.
 
-Follows the IEEE-754 semantics for minNum, except for handling of
-signaling NaNs. This match's the behavior of libm's fmin.
+If the operands compare equal, returns either one of the operands.
 
-If either operand is a NaN, returns the other non-NaN operand. Returns
-NaN only if both operands are NaN. If the operands compare equal,
-returns either one of the operands. For example, this means that
-fmin(+0.0, -0.0) returns either operand.
+Returns -0.0 for +0.0 vs -0.0. libm doesn't require it, so that
+some applications like Clang, can call '``llvm.minnum.*``' with '``nsz``' attribute
+to archive the required behaivors of libm's fmin.
----------------
jcranmer-intel wrote:

I'd reword the second sentence along these lines (unless anyone else has better wording suggestings):

> This behavior is more strict than the definition in C and IEEE 754, where either zero may be returned. To achieve the same permissiveness, one may use the `nsz` attribute on the intrinsic call.

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