This is an archive of the discontinued LLVM Phabricator instance.

[LoopRotate] Attempt to Rotate loops if it can lead to removing phi nodes.
ClosedPublic

Authored by dmgreen on Mar 7 2018, 3:50 AM.

Details

Summary

Fix for a loop-rotation based regression we have seen recently. Prior to rL324572 in
this case we would enter loop rotate with a loop with three blocks, the last of which
is an empty latch. Loop rotate would remove the empty latch, and because it did
(SimplifiedLatch=true), would choose to rotate the loop.

We now remove the empty loop latch in simplifycfg, so loop rotate doesn't find the
latch to simplify (SimplifiedLatch=false), and does nothing with the loop. In this case
the loop keeps track of a current list node and prev list node. Rotating the loop
means we don't need to keep track of prev, removing a phi node.

Diff Detail

Repository
rL LLVM

Event Timeline

dmgreen created this revision.Mar 7 2018, 3:50 AM
efriedma added inline comments.Mar 7 2018, 11:55 AM
lib/Transforms/Scalar/LoopRotation.cpp
181 ↗(On Diff #137353)

A user of an Instruction is always an Instruction, so the isa<> is redundant.

This heuristic doesn't seem very general; it's not clear to me why we specifically want to rotate in cases like this, as opposed to peeling or something like that.

dmgreen updated this revision to Diff 139348.Mar 21 2018, 12:31 PM
dmgreen added inline comments.
lib/Transforms/Scalar/LoopRotation.cpp
181 ↗(On Diff #137353)

Sorry for the delay.

By "not very general", do you mean that this won't catch loops that should be rotated?

Or that this will rotate loops that shouldn't be rotated?

The benchmarks I ran didn't show any regressions from this patch (for what that's worth :) ). I'm just re-running them now to make sure that's still true.

This case is a sorted list insert which I'm trying to come up with a sensible heuristic for. I'll admit I don't think I fully understand why the old heuristic worked (if we remove a latch, then rotate the loop). But at least in this case it did help, so am attempting come up with something that has the same affect.

efriedma added inline comments.Mar 21 2018, 3:02 PM
lib/Transforms/Scalar/LoopRotation.cpp
181 ↗(On Diff #137353)

By "not very general", I mean it happens to match the loop you care about, but doesn't check that the rotated loop will simplify. Even if you find a PHI in the header which matches your pattern, rotating the loop might not remove it.

dmgreen added inline comments.Mar 22 2018, 10:59 AM
lib/Transforms/Scalar/LoopRotation.cpp
181 ↗(On Diff #137353)

Ok. I see. It should be checking that the exit lcssa phi is from the header, not other exits. Otherwise the phi will not be simplified. I'll update things.

dmgreen updated this revision to Diff 139480.Mar 22 2018, 11:20 AM

Changed to check for users in Header's exit.

efriedma added inline comments.Mar 22 2018, 11:56 AM
lib/Transforms/Scalar/LoopRotation.cpp
190 ↗(On Diff #139480)

Is the getIncomingValueForBlock() check necessary? The previous any_of check should enough to ensure we're always eliminating a PHI node, I think?

If it is necessary, please add a testcase demonstrating why.

dmgreen updated this revision to Diff 139519.Mar 22 2018, 3:04 PM
dmgreen added inline comments.
lib/Transforms/Scalar/LoopRotation.cpp
190 ↗(On Diff #139480)

Nice. Like it. I was thinking this felt a bit too specific.

I've updated this and tried to come up with a sensible(ish) test.

Please also add a negative test, that we don't rotate if the PHI is used inside the loop.

dmgreen updated this revision to Diff 139609.Mar 23 2018, 10:48 AM

Added extra test.

This revision is now accepted and ready to land.Mar 23 2018, 11:29 AM
This revision was automatically updated to reflect the committed changes.