[PATCH] D106222: [X86] Don't use known bits to simplify shuffles.

Simon Pilgrim via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Jul 18 05:56:11 PDT 2021


RKSimon added a comment.

In D106222#2885780 <https://reviews.llvm.org/D106222#2885780>, @xiangzhangllvm wrote:

>> The result of a shufflevector must not propagate poison from any element other than the one noted in the shuffle mask.
>> However, this means the 2a419a0b <https://reviews.llvm.org/rG2a419a0b9957ebac9e11e4b43bc9fbe42a9207df> transform isn't safe: if a lane in the result of a shufflevector is supposed to be zero, it has to actually be zero, not zero-or-poison.
>
> Sorry, I still not much understand, where we got the poison value in following transformation.
> computeKnownBits will only meet "AssertZext %f  i8", how does it know there will be poison value ?
>
>   %f = fptoui <4 x float> %arg to <4 x i8> -->   fptosi <4 x float> %1 to <4 x i16> + AssertZext  %f,  i8

It doesn't know there will be poison, it just knows that there COULD be poison.

Unless there's a way to prove that the source float data is 0.0f<x<256.0f then we have to fail safe and assume it could contain poison under some circumstances.

I think we're going to have to add something to the SelectionDAG::computeKnownBits/ComputeNumSignBits doxygen comments explaining that the value could have the determined known/signbits BUT it could be a poison value (or if a vector any demanded element could be poison value).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106222



More information about the llvm-commits mailing list