This is an archive of the discontinued LLVM Phabricator instance.

[LoopUnswitch] Create a PHINode for the original landingpad only if it has some uses
AbandonedPublic

Authored by reames on Jan 6 2016, 11:32 AM.

Details

Reviewers
chenli
Summary

This patch adds a check in UnswitchNontrivialCondition to see if the original landingpad instruction has any uses. If not, we don't need to create a PHINode for it after SplitExitEdges. Please refer to D15835 for the motivation.

Diff Detail

Event Timeline

chenli updated this revision to Diff 44138.Jan 6 2016, 11:32 AM
chenli retitled this revision from to [LoopUnswitch] Create a PHINode for the original landingpad only if it has some uses.
chenli updated this object.
chenli added a reviewer: reames.
chenli added a subscriber: llvm-commits.
reames edited edge metadata.Jan 6 2016, 11:44 AM

Please briefly explain the motivation in this description as well. You want the commit comment to be self explanatory to reviewers and readers of the commit message.

lib/Transforms/Scalar/LoopUnswitch.cpp
1064

I believe this code is wrong as written. If you don't insert the PHI, you still need to replace the original LandingPad with the new one.

chenli added inline comments.Jan 6 2016, 11:49 AM
lib/Transforms/Scalar/LoopUnswitch.cpp
1064

The original LandingPad is in the original loop, and the new LandingPad is in the cloned loop after switch. They will join into the same loop exit block where requires a PHINode which takes both the original landingPad and new LandingPad as incoming values. The original LandingPad should be independent of the new LandingPad and not be replaced.

reames added inline comments.Jan 6 2016, 12:05 PM
lib/Transforms/Scalar/LoopUnswitch.cpp
1064

Oh, you're right. I misread the code as walking the successors rather than the predecessors for some reason.

Though, I gotta admit I'm not quite clear what this code is doing even without your change. The ExitBlock is the one outside the loop right? Why do we believe that all other predecessors to the successor of an exit block are going to also have landing pads just because it does? I'm not following that chain of logic.

Also, the logic in SplitEditBlocks appears like it might be a nop? The docs for SplitBlockPredecessors indicates that Preds is supposed to be a subset of the predecessor blocks. I'm not really sure what this is doing in this case.

chenli added inline comments.Jan 8 2016, 11:25 AM
lib/Transforms/Scalar/LoopUnswitch.cpp
1064

From my understanding, when UnswitchNontrivialCondition happens, it first split loop preheader and loop exits and push them into the clone list. And then it create the new loop by cloning all blocks inside the clone list, where loop preheader and loop exits are all cloned. In other words, the original loop and the newly cloned loop don't share the same loop exits. They each have their own loop exits and joint the exit blocks into exit successors. Therefore, if NewExit has a landingpad, the original exit block should also have a landingpad since that's where NewExit cloned from.

SplitExitBlocks should not be a nop. It basically splits all exit blocks and creates the joint blocks to be used after creating the new loop. In SplitExitBlocks, it does pass all predecessors for each loop exit block into SplitBlockPredecessors function.

reames commandeered this revision.Jun 8 2017, 12:49 PM
reames edited reviewers, added: chenli; removed: reames.
reames abandoned this revision.Jun 8 2017, 12:50 PM

Closing a long abandoned review.