[PATCH] D98410: [ConstantFold] Handle undef/poison when constant folding smul_fix/smul_fix_sat

Thu Mar 11 06:34:00 PST 2021

aqjune added a comment.

In D98410#2619315 <https://reviews.llvm.org/D98410#2619315>, @bjope wrote:

> In D98410#2619250 <https://reviews.llvm.org/D98410#2619250>, @nagisa wrote:
>
>> Wouldn't folding `C * undef` and `undef * C` into an `undef`, rather than `0`, be valid/better? Is there a reason we cannot do that?
>
> I figure that it would be wrong if for example C is zero, because then the result can't take any other value than zero. Or if C is 2 and scale is 0, then the result can't be odd. So undef include values that isn't possible for every combination of the other operands.
>
> The poison propagation is a bit more new for me. I hope I got that part correct.

Yep, this is right.

================
Comment at: llvm/test/Transforms/InstSimplify/ConstProp/smul-fix.ll:148
+  <8 x i3> <i3 undef, i3 2, i3 poison, i3 2, i3 2, i3 2, i3 2, i3 2>,
+  i32 2)
+  ret <8 x i3> %r
----------------
I found from LangRef that actually this can be optimized further:
```
It is undefined behavior if the result value does not fit within the range of the fixed point type.
```

The result of the third element, `llvm.smul.fix.v8i3(2, poison, 2)`, raises UB because `poison` can be folded into a large number which explicitly leads to UB.
Then, output elements not only 3rd/4th but also others are okay to be folded to `poison`.

`udiv <x, x>, <0, 1>` is also returning `<undef, undef>` in the same context currently.

Would this optimization be necessary though? 

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98410/new/

https://reviews.llvm.org/D98410