[PATCH] D126895: [SLP] Phi inputs that come from an unreachable block should be undef.

Nuno Lopes via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 2 11:15:43 PDT 2022


nlopes requested changes to this revision.
nlopes added a comment.

In D126895#3553958 <https://reviews.llvm.org/D126895#3553958>, @vporpo wrote:

> The issue is that the input to SLP contains phis with an undef input when the input is unreachable. Then SLP converts this to poison which I think is not legal.

It is legal. A value from an unreachable branch is not observable, so you can pick whatever you want. We prefer poison as it's the nicest one (as it can be replaced by anything).

> A reduced example of the code that causes the issue looks like this:
>
>   bb1:
>      br label %bb3
>   bb2:
>     br label %bb3
>   bb3:
>    %phi0 = phi i8 [ %a0, %bb1 ], [ 1, %bb2]
>    %phi1 = phi i8 [ %a1, %bb1 ], [ undef, %bb2 ]
>    %zext0 = zext i8 %phi0 to i32
>    %zext1 = zext i8 %phi1 to i32
>    %or = or i32 %zext0, %zext1
>
> %phi1 has an undef input, so %zext1 contains an i32 value with the lower 8-bits being undef. So the %or has the 24 high order bits zero.
>
> SLP converts the undef to poison

That's fine. Moreover, it can then replace %phi1 with %a1.

> which if I understand correctly causes %zext1 and %or to be poison

That shouldn't happen unless it can prove that %a1 is poison.

> OK so if poison is the right value from unreachable blocks, then the issue must be in the pass that generates the undefs in the first place?

No, because the undef is the entry of an unreachable block, so any value is fine. Maybe you've reduced the test case too much. But the bug is surely elsewhere.
Can you share the original test case?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126895



More information about the llvm-commits mailing list