Transformation in alive2: https://alive2.llvm.org/ce/z/7ef9X7

I guess we can make it max(undef, x) => x though.

Sorry, I pasted the wrong code. The test case in the Description is correct.

Here's the buggy one (from Transforms/InstSimplify/floating-point-arithmetic.ll):

define <2 x double> @​maximum_nan_op0_vec(<2 x double> %x) {
; CHECK-LABEL: @​maximum_nan_op0_vec(
; CHECK-NEXT: ret <2 x double> <double 0x7FF8000000000000, double undef>
;
%r = call <2 x double> @​llvm.maximum.v2f64(<2 x double> <double 0x7ff8000000000000, double undef>, <2 x double> %x)
ret <2 x double> %r
}

I guess we can make it max(undef, x) => x though.

Alive2 thinks so :), https://alive2.llvm.org/ce/z/Pzdatp

I'm not sure if it's better, but we are trying to return NAN (rather than the variable operand) in that test, and that should be correct:
https://alive2.llvm.org/ce/z/ysU7Ci

So we matched the partially-defined constant as a NAN, we just failed to propagate the fully-defined NAN from that.

3f100e6

I also see that constant folding isn't fully implemented for any 2-operand FP intrinsics, so at minimum we have some inconsistent behavior (not sure if there are any miscompiles).

I'm not sure if it's better, but we are trying to return NAN (rather than
the variable operand) in that test, and that should be correct:
https://alive2.llvm.org/ce/z/ysU7Ci

So we matched the partially-defined constant as a NAN, we just failed to
propagate the fully-defined NAN from that.

looks even better :)

mentioned in issue #47292