This is an archive of the discontinued LLVM Phabricator instance.

[IVUsers] Check for preheader instead of loop simplify form
ClosedPublic

Authored by nikic on Oct 9 2021, 8:09 AM.

Details

Summary

IVUsers currently makes sure that all loops dominating a user are in loop simplify form, because SCEVExpander needs a preheader to insert into. However, loop simplify form requires much more than that. In particular, it requires dedicated exits, which means that exits need to be found and walked. For large functions with many nested loops, this can result in pathological compile-time explosion.

Fix this by only checking the property we're actually interested in, which is incidentally cheap to check.

Diff Detail

Event Timeline

nikic created this revision.Oct 9 2021, 8:09 AM
nikic requested review of this revision.Oct 9 2021, 8:09 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 9 2021, 8:09 AM
nikic added inline comments.Oct 9 2021, 8:10 AM
llvm/lib/Analysis/IVUsers.cpp
107

This is the only functional change in the patch, the rest is just renames.

mkazantsev accepted this revision.Oct 10 2021, 10:04 PM

Looks fair. Just curious, what's the CT impact?

This revision is now accepted and ready to land.Oct 10 2021, 10:04 PM

LGTM from me as well.

Glancing through the SCEVExpander code, I only see one unconditional use of a preheader assumption, and that looks easy to bail out of. Are you sure we need this restriction at all? (Landing this and then investigating is encouraged.)

nikic added a comment.Oct 11 2021, 1:03 PM

Looks fair. Just curious, what's the CT impact?

For the average case this is only a small improvement: https://llvm-compile-time-tracker.com/compare.php?from=943b3048484b7e3cf04f4d51c23c82fcece2185d&to=272c643a5149425ef577312ae494e726c8b15d9e&stat=instructions

For the pathological case I was looking at compile-time for LSR drops to 40s from previously [unknown but at least 10 minutes].

Glancing through the SCEVExpander code, I only see one unconditional use of a preheader assumption, and that looks easy to bail out of. Are you sure we need this restriction at all? (Landing this and then investigating is encouraged.)

Not sure, but I think the difference to those other usages is that they are only used for optimization, i.e. for basic LICM during expansion. For addrecs having no preheader can make expansion impossible. I guess one would have to check that in isSafeToExpand() instead?

This revision was landed with ongoing or failed builds.Oct 11 2021, 2:13 PM
This revision was automatically updated to reflect the committed changes.