[llvm] [X86] Fix NaN handling in minimumnum/maximumnum zero fixup (PR #217420)

[Oscar Priego via llvm-commits]

================
@@ -27,23 +27,30 @@ declare <4 x bfloat> @llvm.maximumnum.v4bf16(<4 x bfloat>, <4 x bfloat>)
 define float @test_fmaximumnum(float %x, float %y) nounwind {
 ; SSE2-LABEL: test_fmaximumnum:
 ; SSE2:       # %bb.0:
-; SSE2-NEXT:    movaps %xmm0, %xmm3
-; SSE2-NEXT:    maxss %xmm1, %xmm3
+; SSE2-NEXT:    movaps %xmm0, %xmm2
----------------
Opriego wrote:

Yes. I did a narrower comparison by keeping the X86 operations Custom and, immediately after the AVX10.2 native path, temporarily calling expandFMINIMUMNUM_FMAXIMUMNUM() for the numeric variants.

The custom lowering is still clearly better for the general case. With AVX, scalar f32 is 7 instructions versus 13 from the generic helper. For vectors, the difference is much larger because the generic helper takes its explicit unrolling path: <4 x float> is 7 packed instructions versus 58, <8 x float> is 7 versus 118, and AVX-512 <16 x float> is 7 versus 272.

The fast-math cases behave as expected: nnan and nnan nsz are ties, while nsz still favors the custom path. AVX10.2 is unchanged because the native VMINMAX* lowering is selected before the generic-helper experiment.

I also ran the same exact-bit NaN and signed-zero checks through both paths and got identical results.

So the additional operand-1 NaN repair does not appear to remove the benefit of the X86-specific lowering; keeping the focused fix here still seems preferable to falling back to the generic expansion.

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