[llvm] [Sample Profile] Check hot callsite threshold when inlining a function with a sample profile (PR #93286)
William Junda Huang via llvm-commits
llvm-commits at lists.llvm.org
Fri May 24 14:27:50 PDT 2024
huangjd wrote:
> The change is okay but I'm curious who triggered it and have you verify its effectiveness? Asking because the effect of is likely small because if sample loader see a candidate, that means this candidate has been inlined in previous build, so it has passed the threshold/size check in the previous build. Is this change triggered by an actual pathological case where this is leading to huge callee inlined? If so, I'm curious how that happened.
>
> > For example if a function is calling another very large function multiple times (at different code paths), the large function should not be inlined even if its hot.
>
> This should not happen today, the nested callsite / inlinee profile naturally carry context-sensitivity. When determining hotness for sample loader inlining, call site hotness is checked, instead of context-less callee hotness.
>
> cc @helloguo @wlei-llvm
I encountered the issue with some internal protobuf generated c++ compilation, and I assume this applies to other libraries dealing with serialization too. To clarify, this is what I observed to happen, and I made a mistake describing it: `foo` calls `bar` multiple times and each call site is calculated to be hot by the profile , `bar` itself contains many nested function calls that are inlined. `bar` is processed first and after inlining it becomes very large (> 50000 instructions), and `foo` still unconditionally inline every call to `bar` without a cost threshold check.
The reason that `bar` shows up previously inlined in the profile is that another function calling `bar` could be processed before `bar` itself's inlining, and at this point its instruction count is still small
https://github.com/llvm/llvm-project/pull/93286
More information about the llvm-commits
mailing list