This is an archive of the discontinued LLVM Phabricator instance.

[LoopUnswitch] Code refactoring to separate trivial loop unswitch and non-trivial loop unswitch in processCurrentLoop()
ClosedPublic

Authored by chenli on Jul 16 2015, 2:07 PM.

Details

Summary

The current code in LoopUnswtich::processCurrentLoop() mixes trivial loop unswitch and non-trivial loop unswitch together. It goes over all basic blocks in the loop and checks if a condition is trivial or non-trivial unswitch condition. However, trivial unswitch condition can only occur in the loop header basic block (where it controls whether or not the loop does something at all). This refactoring separate trivial loop unswitch and non-trivial loop unswitch. Before going over all basic blocks in the loop, it checks if the loop header contains a trivial unswitch condition. If so, unswitch it. Otherwise, go over all blocks like before but don't check trivial condition any more since they are not possible to be in the other blocks. This code has no functionality change.

Diff Detail

Event Timeline

chenli updated this revision to Diff 29940.Jul 16 2015, 2:07 PM
chenli retitled this revision from to [LoopUnswitch] Code refactoring to separate trivial loop unswitch and non-trivial loop unswitch in processCurrentLoop().
chenli updated this object.
chenli added reviewers: meheff, alexfh, reames.
chenli added a subscriber: llvm-commits.
alexfh removed a reviewer: alexfh.Jul 16 2015, 3:06 PM
reames edited edge metadata.Jul 17 2015, 5:53 PM

Comments inline.

p.s. What's the motivation for this? Is it a step towards a transform or just general code cleanup?

lib/Transforms/Scalar/LoopUnswitch.cpp
834

why is the header the only possible trivial unswitch? (I know the answer, but it's not obvious from the comment.)

835

spelling

841

This code can be greatly simplified by inlining the definition of FindLIVLoopCondition and IsTrivialUnswitchCondition. If I'm reading the code right, you'd basically end up with the existing code in isTrivialUnswitchCondition plus getting the condition from the branch and checking that it's loop invariant.

To put it differently, the generality of this code is actively confusing, not helping.

855

You're missing the NumBranches and NumSwitches statistic updates here. You might be better off introducing new statistics for the trivial cases for reporting though.

Comments inline.

p.s. What's the motivation for this? Is it a step towards a transform or just general code cleanup?

It's actually both. This separation is needed for further improvement on trivial loop unswitch. However, I think it is still a good cleanup if no future patch is landed based on this.

lib/Transforms/Scalar/LoopUnswitch.cpp
834

More comments will be added to address this.

841

I will fix this.

855

I have actually updated NumBranches in the caller of this function. I forgot to separate NumBranches and NumSwitches though. I will redo correctly. Trivial cases are already updated inside UnswitchTrivialCondition function.

chenli edited edge metadata.

Update w.r.t Philip's comments.

After inlining isTrivialUnswitchCondition() into TryTrivialLoopUnswitch(), isTrivialUnswitchCondition() is basically dead code (no use anywhere). A following patch will be submitted to clean it up.

chenli marked 4 inline comments as done.Jul 21 2015, 12:49 PM
broune accepted this revision.Jul 21 2015, 1:30 PM
broune edited edge metadata.

I'd wait to see what reames thinks, but this looks good to me.

This revision is now accepted and ready to land.Jul 21 2015, 1:30 PM

After inlining isTrivialUnswitchCondition() into TryTrivialLoopUnswitch(), isTrivialUnswitchCondition() is basically dead code (no use anywhere). A following patch will be submitted to clean it up.

Please delete it in this commit. It'll generate a warning and some bots treat warnings as errors.

reames accepted this revision.Jul 21 2015, 2:18 PM
reames edited edge metadata.

Really close to ready. I'm not quite willing to give a conditional LGTM, but one more round should do it.

lib/Transforms/Scalar/LoopUnswitch.cpp
466

Why? (in the comment)

845

range for loop

859

This doesn't look correct. The old code doesn't unwitch unless the *condition* is itself the LIV condition. The new code might split an and/or and unsplit one part. Doing that as a separate change is debatable, but not in a refactor please.

In fact, if you could add a negative test case for this, that would be great.

chenli updated this revision to Diff 30287.Jul 21 2015, 2:28 PM
chenli edited edge metadata.

Delete IsTrivialUnswitchCondition() and move related comments to TryTrivialLoopUnswitch()

Philip, sorry I didn't see your inlined comments (I was preparing deleting IsTrivialUnswitchCondition() the same time). I will address it with a new update.

chenli updated this revision to Diff 30297.Jul 21 2015, 3:56 PM

Fixed issue pointed by Philip and added a test case for that.

chenli closed this revision.Jul 21 2015, 10:26 PM