This is an archive of the discontinued LLVM Phabricator instance.

[NewPM][Inliner] Move the 'always inliner' case in the same CGSCC pass as 'regular' inliner
ClosedPublic

Authored by mtrofin on Jan 15 2021, 2:01 PM.

Details

Summary

Expanding from D94808 - we ensure the same InlineAdvisor is used by both
InlinerPass instances. The notion of mandatory inlining is moved into
the core InlineAdvisor: advisors anyway have to handle that case, so
this change also factors out that a bit better.

Diff Detail

Event Timeline

mtrofin created this revision.Jan 15 2021, 2:01 PM
mtrofin requested review of this revision.Jan 15 2021, 2:01 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptJan 15 2021, 2:01 PM
mtrofin updated this revision to Diff 317085.Jan 15 2021, 3:00 PM

patched tests other than Other/<NPM> ones.

We want to rationalize emitting remarks, see also D94334; I'd prefer first landing the always inlining refactoring, because that would impact the remarks refactoring more than vice-versa (I think).

mtrofin retitled this revision from [NewPM]i[Inliner] Move the 'always inliner' case in the same CGSCC pass as 'regular' inliner to [NewPM][Inliner] Move the 'always inliner' case in the same CGSCC pass as 'regular' inliner.Jan 15 2021, 3:00 PM

overall looks good, just a couple small comments

llvm/lib/Analysis/InlineAdvisor.cpp
463

I see this check a lot, should this be handled in some common place instead? Like getMandatoryKind()?

llvm/lib/Analysis/MLInlineAdvisor.cpp
254

Is there a reason to track mandatory inlines? Seems like extra noise

mtrofin marked 2 inline comments as done.Jan 15 2021, 3:08 PM
mtrofin added inline comments.
llvm/lib/Analysis/InlineAdvisor.cpp
463

this is the recursion avoidance test. it's separate from mandatory - I suppose we can factor it upfront.

llvm/lib/Analysis/MLInlineAdvisor.cpp
254

yes, they change the stats that this inline advisor is tracking (currently nr edges, nodes, stuff like that)

aeubanks accepted this revision.Jan 15 2021, 3:18 PM
aeubanks added inline comments.
llvm/lib/Analysis/InlineAdvisor.cpp
463

We don't inline self-recursive CallBases right? Seems like we should always get a Never in that case. But not super important to factor that out right now.

This revision is now accepted and ready to land.Jan 15 2021, 3:18 PM
mtrofin marked 2 inline comments as done.Jan 15 2021, 3:22 PM
mtrofin added inline comments.
llvm/lib/Analysis/InlineAdvisor.cpp
463

right - I kept going back and forth between letting advisors handle that - you could, for example, imagine one that handled recursion and tracked caller/callee to allow a max number of recursive inlinings. But also something that can be factored now, and we deal with it when we get there.

mtrofin updated this revision to Diff 317133.Jan 15 2021, 5:59 PM

updated with all tests

This revision was landed with ongoing or failed builds.Jan 15 2021, 6:31 PM
This revision was automatically updated to reflect the committed changes.
llvm/test/Other/new-pm-lto-defaults.ll