This is an archive of the discontinued LLVM Phabricator instance.

[Loop Peeling] Add support for peeling of loops with multiple exits
ClosedPublic

Authored by skatkov on Jun 28 2019, 1:26 AM.

Details

Summary

This patch modifies the loop peeling transformation so that
it does not expect that there is only one loop exit from latch.

It modifies only transformation. Update of branch weights remains
only for exit from latch.

The motivation is that in follow-up patch I plan to enable loop peeling for
loops with multiple exits but only if other exits then from latch one goes to
block with call to deopt.

For now this patch is NFC.

Diff Detail

Event Timeline

skatkov created this revision.Jun 28 2019, 1:26 AM
fhahn added inline comments.Jun 28 2019, 11:20 AM
include/llvm/Analysis/LoopInfo.h
282 ↗(On Diff #207013)

This is not directly related to the peeling changes. I think it would be better to split this off in a separate patch & also add a test to the loopInfo unit tests with differing const-ness.

lib/Transforms/Utils/LoopUnroll.cpp
407

Unless I am missing something, it looks like Succ here is outside the loop, which would mean that the latch would be an *exiting* block and Succ an *exit* block?

410

IIRC TripCount and TripMultiple would not be set for multi-exit loops (in LoopUnrollPass.cpp), but MaxTripCount would. But maybe I am missing the reasoning behind choosing the trip count of one of the exits?

reames requested changes to this revision.Jun 28 2019, 3:13 PM
This revision now requires changes to proceed.Jun 28 2019, 3:13 PM
skatkov marked 4 inline comments as done.Jul 1 2019, 9:56 PM
skatkov added inline comments.
include/llvm/Analysis/LoopInfo.h
282 ↗(On Diff #207013)
lib/Transforms/Utils/LoopUnroll.cpp
407

Ma bad. It should be latch. Will update a patch.

410

It is not only for multi exit but also for single exit.
We support other exits only for deopts, so no need to worry about them.

skatkov marked an inline comment as done.Jul 1 2019, 9:59 PM
fhahn added inline comments.Jul 2 2019, 5:50 AM
lib/Transforms/Utils/LoopUnrollPeel.cpp
445–449

Maybe assign LatchBR->getNumSuccessors() to a variable, to avoid re-evaluating it?

480–487

Can you use a more descriptive variable name here? Same at line 620

481

Can you use It.second->phis() instead?

skatkov updated this revision to Diff 207716.Jul 3 2019, 12:50 AM

rebase + changes according to review.

skatkov marked 3 inline comments as done.Jul 3 2019, 12:54 AM
fhahn added inline comments.Jul 3 2019, 4:58 AM
lib/Transforms/Utils/LoopUnroll.cpp
410

We support other exits only for deopts, so no need to worry about them.

Right, I missed that restriction. I think it is fine to have this restriction to start with, but it would be good to explicitly mention that here in a comment and in the commit message.

skatkov marked an inline comment as done.Jul 3 2019, 11:00 PM
skatkov added inline comments.
lib/Transforms/Utils/LoopUnroll.cpp
410

To be honest, I' mot sure what exactly you mean. This patch does not modify the guard to allow loops with multiple exits. with this patch we still support only loops with one exit on latch.

The patch does modification to not directly depend on the condition that there is only one exit.
So this particular line change is done because L->getExitingBlock() does not work for multiple exits but we are sure this exiting block is latch and it will be true both for single and multiple exits if others are calls to deopt.

I will update D63923 to comment here about other exits.

fhahn added inline comments.Jul 5 2019, 3:27 AM
lib/Transforms/Utils/LoopUnroll.cpp
410

I meant that I think we were missing an explanation here, for why we would always pick the latch (instead of the getExitingBlock()). Anyways, I missed that in a recent update, you added a comment where you use getLoopLatch, which makes it clear. Thanks

fhahn accepted this revision.Jul 5 2019, 3:35 AM

LGTM, thanks.

I assume @reames marked it as requiring changes due to my comments, but it might be good to wait till early next week, in case he has additional comments.

LGTM, thanks.

I assume @reames marked it as requiring changes due to my comments, but it might be good to wait till early next week, in case he has additional comments.

Nope, purely off your previous comments, don't block on me!

reames accepted this revision.Jul 8 2019, 10:08 AM

Just to clear conflicting phab state.

This revision is now accepted and ready to land.Jul 8 2019, 10:08 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJul 8 2019, 11:09 PM