Logic in this pass assumes that all users of loop instructions are
either in the same loop or are LCSSA Phis. In fact, there can also
be users in unreachable blocks that currently break assertions.
Such users don't need to go to the next round of simplifications.
Details
Diff Detail
Event Timeline
LGTM, thanks! I think it would be good to remove the branch on undef, as per inline comment and possible remove some of blocks that seem unneeded.
llvm/test/Transforms/LoopInstSimplify/pr55072.ll | ||
---|---|---|
6 | nit: the test shouldn't be X86 specific, can this be removed? | |
39 | Those branches look like an artifact of llvm-reduce, where it fails to remove them. Are they needed? | |
43 | Avoiding switching on undef might make the test less prone to unnecessary changes in case loop-instsimplify becomes more powerful in the future. Branch/switch on undef is UB and if the source has UB this will mean verification with tools like Alive2 will always succeed, regardless of what the result of the transform is. |
llvm/test/Transforms/LoopInstSimplify/pr55072.ll | ||
---|---|---|
6 | I guess so. Will update the test before commiting changes. |
llvm/test/Transforms/LoopInstSimplify/pr55072.ll | ||
---|---|---|
39 |
llvm/test/Transforms/LoopInstSimplify/pr55072.ll | ||
---|---|---|
39 | Thanks! |
nit: the test shouldn't be X86 specific, can this be removed?