Zhengyang Liu

2020-09-17 16:23:04 PDT

```Test case from Transforms/InstSimplify/floating-point-arithmetic.ll

define <2 x double> @maxnum_nan_op0_vec(<2 x double> %x) {
; CHECK-LABEL: @maxnum_nan_op0_vec(
; CHECK-NEXT:    ret <2 x double> [[X:%.*]]
;
%r = call <2 x double> @llvm.maxnum.v2f64(<2 x double> , <2 x double> %x)
ret <2 x double> %r
}

The second lane for this case performs the rewrite (llvm.maximum undef, %x) -> undef. The rewrite is illegal. The domain for (llvm.maximum undef, %x) depends on %x, and obviously the result of llvm.maximum does not fully cover the range of undef in most of cases.```

Johannes Doerfert

2020-09-17 17:27:07 PDT

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

Zhengyang Liu

2020-09-17 18:58:27 PDT

```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>
;
%r = call <2 x double> @llvm.maximum.v2f64(<2 x double> , <2 x double> %x)
ret <2 x double> %r
}```

Sanjay Patel

2020-09-18 06:50:59 PDT

```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.```

Johannes Doerfert

2020-09-18 08:32:48 PDT

```(In reply to Sanjay Patel from comment #5)
> 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 :)```