[llvm] SelectionDAG: Support FMINIMUMNUM and FMINIMUM in combineMinNumMaxNumImpl (PR #137449)

[Derek Schuff via llvm-commits]

================
@@ -229,13 +229,10 @@ define float @fminnum32_intrinsic(float %x, float %y) {
 ; CHECK-LABEL: fminnum32_intrinsic:
 ; CHECK:         .functype fminnum32_intrinsic (f32, f32) -> (f32)
 ; CHECK-NEXT:  # %bb.0:
-; CHECK-NEXT:    local.get $push5=, 0
-; CHECK-NEXT:    local.get $push4=, 1
-; CHECK-NEXT:    local.get $push3=, 0
-; CHECK-NEXT:    local.get $push2=, 1
-; CHECK-NEXT:    f32.lt $push0=, $pop3, $pop2
-; CHECK-NEXT:    f32.select $push1=, $pop5, $pop4, $pop0
-; CHECK-NEXT:    return $pop1
+; CHECK-NEXT:    local.get $push2=, 0
+; CHECK-NEXT:    local.get $push1=, 1
+; CHECK-NEXT:    f32.min $push0=, $pop2, $pop1
----------------
dschuff wrote:

@sunfishcode 
It looks like the existing code is incorrect: IIUC `llvm.minnum` is supposed to return a the number if a normal number is compared against a qNaN, and a NaN (with an exception) if a normal number if is compared against a sNaN. Whereas the existing code will always return the LHS (NaN or otherwise if either value is a NaN).

Because Wasm doesn't support FP exceptions and doesn't distinguish between sNaN and qNaN, implementing llvm.minnum directly with Wasm's `f32.min` would make it always return a NaN if either operand is a NaN; which also seems not quite right but is at least consistent? What is the behavior we want here? Is there precedent for how systems that don't support FPEs should treat qNaN vs sNaN?

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