[PATCH] D106053: [CodeGen] Remove pending AssertZext AssertSext in promoting FP_TO_INT

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

In D106053#2885499 <https://reviews.llvm.org/D106053#2885499>, @craig.topper wrote:

> How does poison interact with a bitcast from a wide element type to a narrower element type? Is what computeKnownBits does for this poison safe?

The rules for bitcast are pretty simple, I think: each element of the output vector depends on some number of elements in the input vector.  (In the case of `bitcast <4 x i32> to <16 x i8>`, that's exactly one element.)  If an output element depends on a poisoned input element, the result is poison.

I think computeKnownBits is handling this correctly.

Maybe the following will help clarify: consider the following example:

  define <4 x i32> @src(<4 x float> %a) {
    %u = fptoui <4 x float> <float 256.0> to <4 x i8>
    %z = zext <4 x i8> %u to <4 x i32>
    %and = and <4 x i32> %z, <i32 255, i32 255, i32 255, i32 255>
    ret <4 x i32> %and
  }

It is legal to optimize this to plain "poison".  On the surface, this looks like the same thing as the shufflevector example, but shufflevector itself is sort of special: each element of the output is only poisoned if the corresponding source element is poisoned.


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

https://reviews.llvm.org/D106053