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

[Joshua Cranmer via llvm-commits]

================
@@ -1021,13 +1021,20 @@ enum NodeType {
   LRINT,
   LLRINT,
 
-  /// FMINNUM/FMAXNUM - Perform floating-point minimum or maximum on two
-  /// values.
+  /// FMINNUM/FMAXNUM - Perform floating-point minimum maximum on two values,
+  /// following IEEE-754 definitions except for signed zero behavior.
+  ///
+  /// If one input is a signaling NaN, returns a quiet NaN. This matches
+  /// IEEE-754 2008's minNum/maxNum behavior for signaling NaNs (which differs
+  /// from 2019).
   ///
-  /// In the case where a single input is a NaN (either signaling or quiet),
-  /// the non-NaN input is returned.
+  /// These treat -0 as ordered less than +0, matching the behavior of IEEE-754
+  /// 2019's minimumNumber/maximumNumber.
   ///
-  /// The return value of (FMINNUM 0.0, -0.0) could be either 0.0 or -0.0.
+  /// Note that that arithmetic on an sNaN doesn't consistently produce a qNaN,
+  /// so arithmetic feeding into a minnum/maxnum can produce inconsistent
+  /// results. FMAXIMUN/FMINIMUM or FMAXIMUMNUM/FMINIMUMNUM may be better choice
+  /// for non-distinction of sNaN/qNaN handling.
----------------
jcranmer-intel wrote:

I don't really deal with codegen all that much, so I'm not confident in my assessment here...

Doesn't this change make FMINNUM and FMINNUM_IEEE exactly identical? If so, we should just merge the two of them together and ensure all of the backends are doing the right thing.

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