This is an archive of the discontinued LLVM Phabricator instance.

[LoopInterchange] Make sure we create PHI nodes for uses in split off latch.
AbandonedPublic

Authored by fhahn on Sep 2 2019, 5:47 AM.

Details

Reviewers
efriedma
mcrosier
Summary

We split the original inner loop latch and the split off block becomes
the new outer loop latch after interchanging. We need to introduce new
LCSSA PHIs for values used by instructions in the split off block and
defined in the inner loop.

This patch renames moveLCSSAPHIS and adds support for adding the missing
LCSSA PHIs. Previously moveLCSSAPHIs mixed references to the structure
before and after interchanging. I've updated the naming to be more
explicit and prefixed variables that refer to the structure before
interchanging with Orig.

Fixes PR43176.

Event Timeline

fhahn created this revision.Sep 2 2019, 5:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 2 2019, 5:47 AM
Herald added a subscriber: hiraditya. · View Herald Transcript

I'm not sure how you never hit this issue before. I mean, I can see from the testcase that the compare for the outer loop's branch can end up in the inner loop... but why is it not *always* in the inner loop? What criteria are we using to sink it in some cases? Should we be sinking in all cases?

fhahn added a comment.Sep 5 2019, 11:57 AM

I'm not sure how you never hit this issue before. I mean, I can see from the testcase that the compare for the outer loop's branch can end up in the inner loop... but why is it not *always* in the inner loop? What criteria are we using to sink it in some cases? Should we be sinking in all cases?

Thanks for taking a look! I was surprised as well that this only pops up now. When splitting off the latch, we split at the IV increment instruction. So the IV increment instruction + all instructions after it will end up in the new latch block. I think usually for rotated loops, the incremented IV is used in the exit condition and that is why it only came up now by fuzzing I guess.

I supposes we could instead make sure we split at whatever comes first, IV increment or exit condition. We should probably also make sure we only move the IV increment and exit condition to the new latch. That should probably also be simpler than creating LCSSA phis in those cases. What do you think?

Is there a potential correctness issue here, if some operation that isn't the exit condition or the IV increment somehow ends up in the new latch?

It seems more straightforward to ensure the new latch contains exactly the instructions you expect, rather than creating an LCSSA PHI for a value you've proved is loop-invariant.

fhahn planned changes to this revision.Sep 5 2019, 2:43 PM

Is there a potential correctness issue here, if some operation that isn't the exit condition or the IV increment somehow ends up in the new latch?

I think the current restrictions avoid any problems. We only allow zext, trunc and cmp instructions between the IV increment and the branch inst. If the final value is used outside the loop, that should be fine. A problem could be occur if any of the moved instructions is part of a reduction. I tried and it seems like we do not recognize reductions with trunc/zext chains at the moment, so we should be covered there. But I guess it would be good to make sure the instructions beside the IV increment are only used in the check for the exit condition.

It seems more straightforward to ensure the new latch contains exactly the instructions you expect, rather than creating an LCSSA PHI for a value you've proved is loop-invariant.

Thanks, I'll update the patch

fhahn added a comment.Sep 9 2019, 1:15 PM

I've uploaded a new patch D67367. It duplicates and moves the instructions required in the latch. We have to duplicate the instructions and update its users, if we want to support cases where, for example the condition, gets used in the inner loop body as well.

fhahn abandoned this revision.Sep 11 2019, 3:16 AM

I've committed an alternative fix rL371595. Thanks Eli! I might submit just the renaming/clarifications to moveLCSSAPhis