This is an archive of the discontinued LLVM Phabricator instance.

[JumpThreading] Unfold selects that depend on the same condition
ClosedPublic

Authored by pbarrio on Nov 8 2016, 4:46 AM.

Details

Summary

These are good candidates for jump threading. This enables later opts
(such as InstCombine) to combine instructions from the selects with
instructions out of the selects. SimplifyCFG will fold the select
again if unfolding wasn't worth it.

Patch by James Molloy and Pablo Barrio.

Diff Detail

Repository
rL LLVM

Event Timeline

pbarrio updated this revision to Diff 77171.Nov 8 2016, 4:46 AM
pbarrio retitled this revision from to [JumpThreading] Unfold selects that depend on the same condition.
pbarrio updated this object.
pbarrio added reviewers: sebpop, rengolin.
pbarrio added subscribers: llvm-commits, jmolloy.

Hi @sebpop, @rengolin,

Could you review this patch to JumpThreading? This is an update to D25477, which was reverted two weeks ago as it was breaking LNT and some bootstrap buildbots.

The problem was that an instruction that is used by selects as the condition can be also used as the true or false value. This made the old code insert the "user" select instruction twice in the list of candidates for expansion. When we traversed that list, the instruction was therefore processed twice, but the second time it didn't exist anymore because it had been expanded already into an if-then-else.

The fix is to remove duplicates in the vector of select instructions with sort+unique. A second test has also been added.

rengolin added a subscriber: jojo.Nov 8 2016, 6:12 AM
sebpop accepted this revision.Nov 8 2016, 6:25 AM
sebpop edited edge metadata.

LGTM.

lib/Transforms/Scalar/JumpThreading.cpp
2053 ↗(On Diff #77171)

Note to other reviewers: the above two lines "sort | uniq" are the only change from the previous patch D25477. The explanation of why this is needed is in the first comment from Pablo.

This revision is now accepted and ready to land.Nov 8 2016, 6:25 AM

@sebpop , thanks for the quick response!

This revision was automatically updated to reflect the committed changes.
efriedma added inline comments.
llvm/trunk/lib/Transforms/Scalar/JumpThreading.cpp
2053

This needs a large comment explaining why sorting by pointer addresses doesn't introduce non-determinism.

efriedma added inline comments.Nov 8 2016, 12:02 PM
llvm/trunk/lib/Transforms/Scalar/JumpThreading.cpp
2053

Actually, thinking about it a bit more, I'm 99% sure this does introduce non-determinism, at least in the ordering of use-lists. Could you use a SetVector here instead?

Thanks for the comment @efriedma. I committed before I saw it, but I agree with you that this change will affect determinism of the use-lists when two of the selects on the list depend on each other. I will create a separate revision for the change and add you as reviewer.