This is an archive of the discontinued LLVM Phabricator instance.

[NewPM] Only invalidate modified functions' analyses in CGSCC passes + turn on eagerly invalidate analyses
ClosedPublic

Authored by aeubanks on Nov 5 2021, 11:51 AM.

Details

Summary

Previously, any change in any function in an SCC would cause all
analyses for all functions in the SCC to be invalidated. With this
change, we now manually invalidate analyses for functions we modify,
then let the pass manager know that all function analyses should be
preserved since we've already handled function analysis invalidation.

So far this only touches the inliner, argpromotion, function-attrs, and
updateCGAndAnalysisManager(), since they are the most used.

This is part of an effort to investigate running the function
simplification pipeline less on functions we visit multiple times in the
inliner pipeline.

However, this causes major memory regressions especially on larger IR.
To counteract this, turn on the option to eagerly invalidate function
analyses. This invalidates analyses on functions immediately after
they're processed in a module or scc to function adaptor for specific
parts of the pipeline.

Within an SCC, if a pass only modifies one function, other functions in
the SCC do not have their analyses invalidated, so in later function
passes in the SCC pass manager the analyses may still be cached. It is
only after the function passes that the eager invalidation takes effect.
For the default pipelines this makes sense because the inliner pipeline
runs the function simplification pipeline after all other SCC passes
(except CoroSplit which doesn't request any analyses).

Overall this has mostly positive effects on compile time and positive effects on memory usage.
https://llvm-compile-time-tracker.com/compare.php?from=7f627596977624730f9298a1b69883af1555765e&to=39e824e0d3ca8a517502f13032dfa67304841c90&stat=instructions
https://llvm-compile-time-tracker.com/compare.php?from=7f627596977624730f9298a1b69883af1555765e&to=39e824e0d3ca8a517502f13032dfa67304841c90&stat=max-rss

D113196 shows that we slightly regressed compile times in exchange for
some memory improvements when turning on eager invalidation. D100917
shows that we slightly improved compile times in exchange for major
memory regressions in some cases when invalidating less in SCC passes.
Turning these on at the same time keeps the memory improvements while
keeping compile times neutral/slightly positive.

Diff Detail

Event Timeline

aeubanks created this revision.Nov 5 2021, 11:51 AM
aeubanks requested review of this revision.Nov 5 2021, 11:51 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptNov 5 2021, 11:51 AM
nikic added a comment.Nov 5 2021, 2:58 PM

I don't think I fully understand the interaction this has with eager invalidation. I would have expected that if we eagerly invalidate, then this fine-grained invalidation wouldn't make much of a difference, because we invalidate anyway after processing a function.

llvm/lib/Transforms/IPO/ArgumentPromotion.cpp
1050
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
1843

Do we need to worry about indirect references here, like a call through a bitcast? For the ArgPromotion case that's not possible, but I'm not so sure here.

aeubanks updated this revision to Diff 385539.Nov 8 2021, 9:49 AM

address comments
[argpromo] only invalidate direct callers that call the function, not if the function is a parameter

llvm/lib/Transforms/IPO/FunctionAttrs.cpp
1843

I suppose it's possible for analyses to look at all references to other functions and look at attributes of those functions, but I can't really imagine that happening in practice. AFAICT everything that looks at function attributes only does so for direct calls.

I don't think I fully understand the interaction this has with eager invalidation. I would have expected that if we eagerly invalidate, then this fine-grained invalidation wouldn't make much of a difference, because we invalidate anyway after processing a function.

if we've already calculated e.g. DT for all functions in an SCC prior to visiting the SCC, currently if an SCC pass changes any of the functions, we'd invalidate analyses for all the functions in the SCC, meaning function passes in the SCC adaptor would have to recalculate. but if we do this fine-grained invalidation we won't have to recalculate DT in the function passes for functions that weren't modified in the SCC pass

I'll add this to the description

aeubanks edited the summary of this revision. (Show Details)Nov 8 2021, 10:08 AM
aeubanks edited the summary of this revision. (Show Details)Nov 8 2021, 1:51 PM

Thank you for the additional clarifications in the comments and descriptions!

The invalidations are essentially postponed until after the function simplification pipeline with this patch.
Before, everything was invalidated in the SCC pass even if only one function was touched, and nothing was invalidated after the function passes. With this patch, only what is touched is invalidated in the SCC pass, then function passes that follow find analyses available (where functions were unmodified), and only afterwards all function analyses are invalidated in the ModuleToFunction adaptor. The balance is from turning on both D113196 and D100917.

mtrofin added inline comments.Nov 8 2021, 3:23 PM
llvm/lib/Transforms/IPO/Inliner.cpp
1017

Should we do this if !Changed? Actually, if this function did not change (Changed is per cgscc)

aeubanks added inline comments.Nov 8 2021, 3:32 PM
llvm/lib/Transforms/IPO/Inliner.cpp
1017

we already bail out at line 966 if this function hasn't been changed

asbirlea accepted this revision.Nov 9 2021, 2:42 PM

LGTM, but please wait to see if @nikic has additional comments.

This revision is now accepted and ready to land.Nov 9 2021, 2:42 PM
nikic accepted this revision.Nov 9 2021, 2:55 PM

LGTM as well.

This revision was landed with ongoing or failed builds.Nov 15 2021, 2:47 PM
This revision was automatically updated to reflect the committed changes.