This is an archive of the discontinued LLVM Phabricator instance.

[NewPM] Only invalidate modified functions' analyses in CGSCC passes
AbandonedPublic

Authored by aeubanks on Apr 20 2021, 6:39 PM.

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.

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

Slight compile time improvements:
http://llvm-compile-time-tracker.com/compare.php?from=326da4adcb8def2abdd530299d87ce951c0edec9&to=8942c7669f330082ef159f3c6c57c3c28484f4be&stat=instructions

Diff Detail

Event Timeline

aeubanks created this revision.Apr 20 2021, 6:39 PM
aeubanks requested review of this revision.Apr 20 2021, 6:39 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 20 2021, 6:39 PM

I'm happy to split this up, I'd just like to know if this is reasonable.

check-llvm with expensive checks passes.

mtrofin accepted this revision.Apr 20 2021, 7:47 PM

lgtm

This revision is now accepted and ready to land.Apr 20 2021, 7:47 PM
ychen added a subscriber: ychen.Apr 20 2021, 10:56 PM

I think we should be careful about letting passes invalidate analyses directly. IIUC the only interface for propagating invalidation from passes is PreservedAnalyses. Is there any way to enhance PreservedAnalyses to achieve the same effect?

It seems awkward to enhance PreservedAnalyses to only apply to specific functions when this patch is explicitly doing exactly what we want. If you have a clean way of modeling this inside PreservedAnalyses I'm happy to go with that, but so far I think this is the cleanest way.
Passes were already directly managing the analysis managers, e.g. the inliner and argpromo would remove entries for deleted functions. And updateCGAndAnalysisManager() would also handle analysis manager updates.

ychen added a comment.Apr 21 2021, 4:57 PM

It seems awkward to enhance PreservedAnalyses to only apply to specific functions when this patch is explicitly doing exactly what we want. If you have a clean way of modeling this inside PreservedAnalyses I'm happy to go with that, but so far I think this is the cleanest way.

I was thinking something like PreservedAnalyses::abandon(IRUnit, AnalysisID) which only used to selectively invalidate inner IR units, but I've convinced myself that it may not worth it. Invalidating inner analyses through proxy should work well already.

Passes were already directly managing the analysis managers, e.g. the inliner and argpromo would remove entries for deleted functions. And updateCGAndAnalysisManager() would also handle analysis manager updates.

I would argue that updateCGAndAnalysisManager() is kinda special (for coping with the CGSCCPM's complexity). I think the one in argpromo is not necessary since it already returns PreservedAnalyses::none(). inliner yes.

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

Is the function CFG preserved?

aeubanks added inline comments.Apr 21 2021, 9:34 PM
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
1631

Yes, will update.
Doing this causes globalaa-retained.ll to fail, which I believe is fixed by https://reviews.llvm.org/D101017

aeubanks updated this revision to Diff 339782.Apr 22 2021, 2:19 PM

add test
use CFGAnalyses
uncovered another place in updateCGAndAnalysisManager() to change

depends on D101017

Herald added a project: Restricted Project. · View Herald TranscriptApr 22 2021, 2:19 PM
aeubanks edited the summary of this revision. (Show Details)Apr 22 2021, 2:20 PM
This revision was landed with ongoing or failed builds.May 3 2021, 5:22 PM
This revision was automatically updated to reflect the committed changes.
nikic added a comment.May 4 2021, 12:36 AM

An unfortunate side-effect of this change is that NewPM uses even more memory. tramp3d-v4 is up 20% in max-rss (https://llvm-compile-time-tracker.com/compare.php?from=4ef1f90e4d564b872e3598ccef45adb740eb0f0d&to=d14d84af2f5ebb8ae2188ce6884a29a586dc0a40&stat=max-rss)

An unfortunate side-effect of this change is that NewPM uses even more memory. tramp3d-v4 is up 20% in max-rss (https://llvm-compile-time-tracker.com/compare.php?from=4ef1f90e4d564b872e3598ccef45adb740eb0f0d&to=d14d84af2f5ebb8ae2188ce6884a29a586dc0a40&stat=max-rss)

Hmm that is a concern. I'm not sure how we want to balance memory vs compile times. Any thoughts?

An unfortunate side-effect of this change is that NewPM uses even more memory. tramp3d-v4 is up 20% in max-rss (https://llvm-compile-time-tracker.com/compare.php?from=4ef1f90e4d564b872e3598ccef45adb740eb0f0d&to=d14d84af2f5ebb8ae2188ce6884a29a586dc0a40&stat=max-rss)

Hmm that is a concern. I'm not sure how we want to balance memory vs compile times. Any thoughts?

(Drive-by thought) - maybe this is because a bunch of analyses that are needed during function simplification aren't needed anymore after. We could quickly check by adding a pass at the end of all function simplification, module-wide, that clears all fct analyses, and see if the memory overhead is still there?

If that's the case, we could identify what's not needed after function simplification and scope it somehow in a less hacky way than my above suggestion.

aeubanks reopened this revision.Jun 3 2021, 4:16 PM

Using valgrind's massif, I profiled using clang build build PassBuilder.cpp (it's one of the longest LLVM files to compile), and at peak memory usage:

without patch: 42.5% Clang AST, 11.6% misc, 5.6% BlockFrequencyInfo, 3.3% DomTree, 1.4% LazyCallGraph, 1.2% MemorySSA
with patch: 37.6% Clang AST, 12.7% misc, 4.9% BlockFrequencyInfo, 3.4% MemorySSA, 3.2% DomTree, 1.7% BlockProbabilityInfo (again), 1.2% LazyCallGraph
misc means anything below 0.3%
(I'm ignoring some LLVM non-analysis and Clang stuff)
assuming that the Clang AST is mostly constant between the two, it does look like my patch (https://reviews.llvm.org/D100917) does slightly increase memory usage, at least just for some random file (PassBuilder.cpp), and some files are likely to be much worse due to more SCCs. and there's no obvious large analysis to clear out

I'll look to see if we really need the Clang AST while running passes, although I'm not hopeful there

This revision is now accepted and ready to land.Jun 3 2021, 4:16 PM

I rebased this and there are still major memory regressions for tramp3d-v4: https://llvm-compile-time-tracker.com/compare.php?from=f63405f6e3d30f33e715ef5ad09136127535a3fb&to=ae5555c1375e4afe90727f1c30dae1659d11a20d&stat=max-rss
Perhaps we can't land this in its current form. Will need to rethink an alternative to push ahead with D98103

aeubanks planned changes to this revision.Nov 1 2021, 4:32 PM
ormris removed a subscriber: ormris.Jan 24 2022, 11:20 AM
aeubanks abandoned this revision.Feb 15 2022, 1:43 PM