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

Bjorn Pettersson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 11 07:00:16 PST 2021


bjope added a comment.

In D98410#2619538 <https://reviews.llvm.org/D98410#2619538>, @nagisa wrote:

> In D98410#2619315 <https://reviews.llvm.org/D98410#2619315>, @bjope wrote:
>
>> So undef include values that isn't possible for every combination of the other operands.
>
> Aha, I see! This is an interesting reasoning. I think it is fine to do what you're doing for the sake of simplicity, what follows under the horizontal line below is a bunch of my rambling (feel free to ignore all of it)
>
> ---
>
> Taking a regular `mul` instruction as an example
>
>   mul i32 1, undef  # => undef
>   mul i32 2, undef  # => 0
>   mul i32 3, undef  # => undef
>
> These make sense to me, though require some roundabout reasoning. `1 * undef = undef` is trivial. `2 * undef` follows the same reasoning as yours in that there's bit-pattern `undef` can take that would result in lower bit set here. That same reasoning could apply for `3 * undef` too – but it does not because of wrap-around (I think).
>
> And this is where the following snippet from the smul.fix <https://llvm.org/docs/LangRef.html#llvm-smul-fix-intrinsics> definition comes in:
>
>> It is undefined behavior if the result value does not fit within the range of the fixed point type.
>
> Basically, unless the intrinsic is multiplying `undef` by `1` or by `0`, I believe there's an implicit invocation of UB. That's because there exist bit patterns of an `undef` operand that multiplied by other values would cause the resulting value to not fit within the fixed point type's range (right?). Whether we manifest this UB as `undef` or `0` probably doesn't matter too much, but I //think// either option would be valid.

It depends a bit on the scale. If you for example multiply by 0.5 then you won't get any overflow. On the other hand, smul.fix with scale=0 is pretty much like a regular mul but not sure we need to make a special case for that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98410



More information about the llvm-commits mailing list