This is an archive of the discontinued LLVM Phabricator instance.

[SCEV] Track backedge taken count users (NFCI)
ClosedPublic

Authored by nikic on Nov 30 2021, 2:29 AM.

Details

Summary

Track which SCEVs are used as ExactNotTaken counts in BackedgeTakenInfo structures, so we can directly determine which loops need to be invalidated, rather than iterating over all BECounts.

This gives a small compile-time improvement on average (https://llvm-compile-time-tracker.com/compare.php?from=77dd579827f2e7574be4bbf3f94a48930e7b094f&to=72d45d2131f55751be7654e5d13115fe5b150dbb&stat=instructions), but the motivation here is more to ensure there are no degenerate cases, if the number of backedge taken counts is large.

Diff Detail

Event Timeline

nikic created this revision.Nov 30 2021, 2:29 AM
nikic requested review of this revision.Nov 30 2021, 2:29 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 30 2021, 2:29 AM
reames requested changes to this revision.Nov 30 2021, 8:43 AM
reames added inline comments.
llvm/lib/Analysis/ScalarEvolution.cpp
7892

Basic idea makes sense, but I really think the user tracking should be here. Much easier to tell for sure we caught everything.

For one thing, you don't appear to be tracking the constantmax information in your patch, and I think we do need to add that.

12877

Personally, I'd write this as:
assert BECountUsers.count(ENT.ExactNotTaken)
BECountUsers.erase(ENT.ExactNotTaken)

I often find the use of iterators confusing, and prefer to avoid them for simple asserts. Why reason about potential invalidation when you don't have to?

This revision now requires changes to proceed.Nov 30 2021, 8:43 AM
nikic added inline comments.Nov 30 2021, 9:39 AM
llvm/lib/Analysis/ScalarEvolution.cpp
7892

Basic idea makes sense, but I really think the user tracking should be here. Much easier to tell for sure we caught everything.

Generally agree -- reason I didn't put it in here is that the user tracking is on ScalarEvolution, so we'd have to pass it in and make BackedgeTakenInfo a friend class. The resulting layering seems a bit odd.

For one thing, you don't appear to be tracking the constantmax information in your patch, and I think we do need to add that.

I intentionally dropped the ConstantMax part, because it always stores a SCEVConstant, which can never be invalidated (for ExactNotTaken, only non-SCEVConstants are tracked as well). We don't track ENT.MaxNotTaken (both before and after this patch) for the same reason, it's always constant.

reames accepted this revision.Nov 30 2021, 9:51 AM

Thanks for explaining.

LGTM w/suggested, but not required changes.

llvm/lib/Analysis/ScalarEvolution.cpp
7892

On the placement, maybe move it just before the return which constructs the BackedgeTakenInfo? Or at least add an assert there to make sure we covered all the exit cases? I'm worried about someone complicating the flow through that method and forgetting to update the users.

Oh! That reminds me, we should really be verifying this. (i.e, making sure our user sets are in sync with the forward direction) I'm fine having that in a separate patch, but can you make sure that happens?

On the ConstantMax case, makes sense. Can you make sure to add a comment somewhere emphasizing the subtlety?

This revision is now accepted and ready to land.Nov 30 2021, 9:51 AM
This revision was automatically updated to reflect the committed changes.