[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