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

[Craig Topper via Phabricator via llvm-commits]

craig.topper added a comment.

In D106053#2885500 <https://reviews.llvm.org/D106053#2885500>, @efriedma wrote:

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

Ok that makes sense if the bitcast existed in IR. But this bitcast was created as part of type legalization and potentially spread poison to adjacent elements that didn't happen in the IR.


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

https://reviews.llvm.org/D106053