This is an archive of the discontinued LLVM Phabricator instance.

[LoopFlatten] Use SCEV and Loop APIs to identify increment and trip count
ClosedPublic

Authored by RosieSumpter on Jul 22 2021, 11:51 AM.

Details

Summary

Replace pattern-matching with existing SCEV and Loop APIs as a more
robust way of identifying the loop increment and trip count. Also
rename 'Limit' as 'TripCount' to be consistent with terminology.

Diff Detail

Event Timeline

RosieSumpter created this revision.Jul 22 2021, 11:51 AM
RosieSumpter requested review of this revision.Jul 22 2021, 11:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 22 2021, 11:51 AM
SjoerdMeijer added inline comments.Jul 23 2021, 1:38 AM
llvm/lib/Transforms/Scalar/LoopFlatten.cpp
134

I am not sure if an induction phi can have > 2 incoming values. If it can then the assert needs to be a return, and a test case is missing for this.

But if getNumIncomingValues() == 2 is guaranteed by getInductionVariable(), then this is fine. Can you double check by looking at getInductionVariable()?

155–156

Just for clarity, I was wondering if we should rename limit to trip count, because that is what it is at the moment with the restriction that our loops start counting at 0. I think that makes things clearer now that we start using SCEV and request trip counts.

RosieSumpter retitled this revision from [LoopFlatten] Use SCEV and Loop APIs to identify increment and limit to [LoopFlatten] Use SCEV and Loop APIs to identify increment and trip count.
RosieSumpter edited the summary of this revision. (Show Details)
  • Removed assert on the number of incoming phi values
  • Rename 'Limit' to 'TripCount' for consistency
RosieSumpter marked an inline comment as done and an inline comment as not done.Jul 23 2021, 5:24 AM
RosieSumpter added inline comments.
llvm/lib/Transforms/Scalar/LoopFlatten.cpp
134

This assert was actually already there, I just moved it up to be where the induction phi is identified. But I agree, since the loop is in simplified form it will only have 2 incoming values so I'll remove this assert.

SjoerdMeijer added inline comments.Jul 23 2021, 6:47 AM
llvm/lib/Transforms/Scalar/LoopFlatten.cpp
74

Perhaps we can document some assumptions and limitations here.

79

This corresponds to a loop induction variable, which we expect to have a start value of 0.

155–156

Perhaps I have a slight preference here for:

f (!L->isCanonical(*SE))
  return false;

so we don't need the Increment = nullptr; here.

155–156

Then, this can just be:

if (Increment->hasNUsesOrMore(3))
155–156

Ah, nice one, isCanonical checks exactly what we were assuming and pattern matching: it checks that the loop starts at 0 and increments by 1. Do we need the isZero() check above?

  • Added comment about induction variable assumptions
  • Moved isCanonical check on loop to be higher so we exit earlier if loop is not canonical
  • Removed Increment = nullptr
  • Removed code which determines trip count in the case where another transformation changes the compare, and return false instead (and added negative test case for this)
RosieSumpter marked 3 inline comments as done.Jul 23 2021, 8:49 AM
SjoerdMeijer added inline comments.Jul 26 2021, 12:10 AM
llvm/lib/Transforms/Scalar/LoopFlatten.cpp
165

Can this be !=?

165–190

We are not doing this sanity check when the IV is widened.
Can we also check this case and do something like this?

ExtTC = Tripcount->getOperand(0);
if (!isa<ZExt>(ExtTC) || !isa<SExt>(ExtTC) ||
    SE->getSCEV(ExtTC) != SCEVTripCount ) {
  LLVM_DEBUG(dbgs() << "Could not find valid extended trip count\n");
  return false;
}
RosieSumpter set the repository for this revision to rG LLVM Github Monorepo.

Added a check on the trip count when the IV is widened

RosieSumpter marked 2 inline comments as done.Jul 26 2021, 5:24 AM

Amended the check on the trip count when the IV has been widened

SjoerdMeijer accepted this revision.Jul 26 2021, 8:38 AM

Thanks, nice change that gets rid of quite some pattern matching!

This revision is now accepted and ready to land.Jul 26 2021, 8:38 AM
fhahn added inline comments.Jul 26 2021, 8:46 AM
llvm/lib/Transforms/Scalar/LoopFlatten.cpp
109

This is just a limitation to keep the implementation simpler at the moment right? Might be worth clarifying in the comment.

160

Is later code somewhere relying that the increment is an add instruction? What if it is something like an extend?

RosieSumpter added inline comments.Jul 26 2021, 9:23 AM
llvm/lib/Transforms/Scalar/LoopFlatten.cpp
109

Ok sure, there is also a note mentioning this in lines 77/78. I will add some clarification that this is to simplify the implementation before committing.

160

No, we don't rely on it being an Add instruction. Using SCEV, it is now guaranteed that the loop starts at 0 and increments with 1. Most of the pattern matching that we replaced was to ensure that. The increment is also marked as an "IterationInstruction", but that's only for cost-modeling purposes and it doesn't rely on Adds.

This revision was landed with ongoing or failed builds.Jul 27 2021, 1:02 AM
This revision was automatically updated to reflect the committed changes.