This is an archive of the discontinued LLVM Phabricator instance.

[IRCE] Return "Identify loops with latch comparison against current IV value"
AbandonedPublic

Authored by mkazantsev on Aug 2 2017, 4:17 AM.

Details

Summary

The patch was reverted by rL312783 due to failures on internal tests. The failures are fixed
in this revision, specifically the previous version of the patch missed updates of GreatestSeen
and Smallest values in case of comparison against current IV value.

Current implementation of parseLoopStructure interprets the latch comparison as a
comarison against iv.next. If the actual comparison is made against the iv current value
then the loop may be rejected, because this misinterpretation leads to incorrect evaluation
of the latch start value.

This patch teaches the IRCE to distinguish this kind of loops and perform the optimization
for them. Now we use IndVarBase variable which can be either next or current value of the
induction variable (previously we used IndVarNext which was always the value on next iteration).

Diff Detail

Event Timeline

mkazantsev planned changes to this revision.Aug 2 2017, 9:46 PM

Our internal testing has detected some bugs with this patch, so I will fix them and re-submit the fixed version.

mkazantsev edited the summary of this revision. (Show Details)

Fixed the bug that was found on internal testing, extended tests.

mkazantsev updated this revision to Diff 110347.Aug 9 2017, 4:03 AM

Split into two parts (NFC rename and new logic) to make it easier to review.

mkazantsev updated this revision to Diff 110348.Aug 9 2017, 4:07 AM
mkazantsev planned changes to this revision.Aug 9 2017, 11:02 PM

One more (rare) failure was found on internal testing. Need to investigate it. Also need to extend the test base.

Fixed the problem with incorrect end value in changeIterationSpaceEnd, updated tests wrt this change.

anna requested changes to this revision.Aug 17 2017, 6:41 AM

Comments inline.

lib/Transforms/Scalar/InductiveRangeCheckElimination.cpp
501

Pls add a comment for what IndVarBase and IndVarNext means. It's pretty clear in the summary of the bug, but add it as a comment in the code as well.

882

Pls add a comment that this checks that the comparison is made against iv.next.

890

I'm not sure if this is enough to identify that it's from the current IV.

What if we had some "noop" operations on that phi node, and the result of that operation was used in the comparison? Wouldn't we incorrectly mark as this is from iv.next, whereas it's infact from the current IV.

header:
iv = phi [0, entry] [iv.next, latch]
...

latch:
iv.trunc =  trunc iv to 16
iv.next = iv + 1
%cmp = slt iv.trunc, 100
br %cmp, header, exit

It could be bitcast or trunc or any other such operations. I think we need to "look through these operations" rather than directly comparing against a phi node.

Please add test cases as well.

This revision now requires changes to proceed.Aug 17 2017, 6:41 AM
mkazantsev added inline comments.Aug 18 2017, 5:46 AM
lib/Transforms/Scalar/InductiveRangeCheckElimination.cpp
890

In current implementation, such case will be still recognized as comparison against iv.next. That's an interesting point, I need to think on it. Thanks for noticing that!

mkazantsev marked 3 inline comments as done.Aug 23 2017, 2:55 AM
mkazantsev added inline comments.
lib/Transforms/Scalar/InductiveRangeCheckElimination.cpp
890

I checked that they follow by iv.next branch and get rejected on iteration range safety stage. Given that this behavior also exists without this patch, this doesn't seem to produce bugs. Added a TODO to handle these cases by the first branch as a scope improvement.

mkazantsev edited edge metadata.

Added some clarifying comments & tests.

anna added a comment.Aug 25 2017, 6:18 AM

Max, could you please update the patch with full context?

Oh. My bad. Re-uploaded version with context.

anna accepted this revision.Aug 30 2017, 6:27 AM

LGTM

This revision is now accepted and ready to land.Aug 30 2017, 6:27 AM
This revision was automatically updated to reflect the committed changes.
mkazantsev reopened this revision.Sep 7 2017, 9:39 PM

This one was reverted due to found bug, I'm working on fix.

This revision is now accepted and ready to land.Sep 7 2017, 9:39 PM

Fixed buggy tests & code, added a new test.

This revision was automatically updated to reflect the committed changes.
mkazantsev retitled this revision from [IRCE] Identify loops with latch comparison against current IV value to [IRCE] Return "Identify loops with latch comparison against current IV value".
mkazantsev edited the summary of this revision. (Show Details)

The patch was reverted by rL312783 due to failures on internal tests. The failures are fixed
in this revision, specifically the previous version of the patch missed updates of GreatestSeen
and Smallest values in case of comparison against current IV value.

Failures fix, resubmitting for review.

mkazantsev reopened this revision.Oct 12 2017, 4:53 AM
This revision is now accepted and ready to land.Oct 12 2017, 4:53 AM
mkazantsev requested review of this revision.Oct 12 2017, 4:53 AM
mkazantsev edited edge metadata.
mkazantsev planned changes to this revision.Oct 12 2017, 9:45 PM

Need to simplify the new tests slightly.

Simplified tests 06-09 (that exercise the last found problem) slightly. Also added a comment.

mkazantsev planned changes to this revision.Jan 7 2018, 5:58 PM

Needs to be ported on top of current code base.

mkazantsev abandoned this revision.Feb 14 2018, 3:31 AM

No plan to return it in near future, maybe will be required later.