This is an archive of the discontinued LLVM Phabricator instance.

[LoopInterchange] Remove a limitation in legality
ClosedPublic

Authored by congzhe on Dec 7 2021, 4:47 AM.

Details

Summary

There was a limitation that in the inner loop latch, no instruction was allowed between induction variable increment and branch in the inner loop latch. This is because we used to split the inner latch at the induction variable increment instruction. Since now we have split at the inner latch branch instruction and have moved instructions properly, we remove this limitation.

As an example, please refer to interchange_10() in test/Transforms/LoopInterchange/interchangeable.ll for the interchanged loop generated after loop interchange:

The inner latch is BB for2. When this pass was introduced very early on, it would split for2 at %j.next = add nuw nsw i64 %j, 1, and all instructions after %j.next would go into the split BB which will become the new outer latch. This causes incorrectness and hence the limitation that
" no instruction was allowed between induction variable increment and branch in the inner loop latch" was introduced initially.

Right now we split at the branch instruction of for2, and we duplicate %j.next = add nuw nsw i64 %j, 1 and %exitcond = icmp eq i64 %j, 99 into for2.split which becomes the new outer latch. Instructions in the original inner latch stay where they are. Hence the limitation can be removed.

Hope my explanation is clear, if there is any confusion please feel free to comment.

Diff Detail

Event Timeline

congzhe created this revision.Dec 7 2021, 4:47 AM
congzhe requested review of this revision.Dec 7 2021, 4:47 AM
congzhe edited the summary of this revision. (Show Details)Dec 7 2021, 5:27 AM
congzhe added a reviewer: Restricted Project.Dec 20 2021, 11:55 AM

Right now we split at the branch instruction of for2, and we duplicate %j.next = add nuw nsw i64 %j, 1 and %exitcond = icmp eq i64 %j, 99 into for2.split which becomes the new outer latch. Instructions in the original inner latch stay where they are. Hence the limitation can be removed.

Do we check to make sure duplicating instructions is safe (eg we are not duplicating side effects, etc)?

Right now we split at the branch instruction of for2, and we duplicate %j.next = add nuw nsw i64 %j, 1 and %exitcond = icmp eq i64 %j, 99 into for2.split which becomes the new outer latch. Instructions in the original inner latch stay where they are. Hence the limitation can be removed.

Do we check to make sure duplicating instructions is safe (eg we are not duplicating side effects, etc)?

Thanks for the comment!

Yes we did. The check is at line 1314:

assert(!NewI->mayHaveSideEffects() &&
               "Moving instructions with side-effects may change behavior of "
               "the loop nest!");

Relevant comment: https://reviews.llvm.org/D67367?vs=219418&id=219529#1664596.

It is not very easy to come up with a test case that involves duplicating unsafe instructions though, because the instructions we duplicate are involved in the loop exit condition or the induction variable increment. If an unsafe instruction was involved in loop exit condition or the induction variable increment, SCEV would say it cannot compute the backedge count and we would bail out at the first place, not even reach this piece of code.

bmahjour accepted this revision as: bmahjour.Jan 5 2022, 2:32 PM

LGTM. Thanks!

This revision is now accepted and ready to land.Jan 5 2022, 2:32 PM