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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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).
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. |
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. |
I see this check a lot, should this be handled in some common place instead? Like getMandatoryKind()?