[llvm] [LTO][Pipelines] Add 0 hot-caller threshold for SamplePGO + FullLTO (PR #135152)

[Mingming Liu via llvm-commits]

mingmingl-llvm wrote:

> I observed an interpreter kind benchmark could find correct profiling info after the patch (This is my motivation of the patch). For spec2017 c/c++ cases, with unchanged profile file, I could see 12 cases in total16 binaries have changed after the patch. But none of them has performance change. :(

Thanks for sharing. I'm asking mainly because the applications that I work on are not built with full LTO and I don't have existing scripts/tools to test fullLTO. 

> So setting HotCallSiteThreshold to 0 in pre-link stage would not change final inlining result, because the hot callsite functions just to be postponed to inline in link stage

Given a whole program call graph (a directed graph possibly with cycles), the LLVM inliner works bottom-up in the graph and function size is used by the heuristics. So theoretically suppressing hot functions in prelink (until postlink) may change the inline result. But I consider the different inline result secondary effect and will not try to reason about the performance effect from it.

> And as you commented in code ... why we don't set HotCallSiteThreshold to INT_MIN to completely stop hot callsite inline in pre-link

https://reviews.llvm.org/D31201 did this optimization for SampleFDO + ThinLTO, and the comment mainly makes it explicit that hot callsite function with zero or negative cost still would be inlined in pre-link stage as a clarification. My understanding about this (not setting HotCallSiteThreshold to INT_MIN) is that small functions (with zero or negative cost) will be inlined similarly in the profiled binary or in the optimized binary, so they don't cause profile mismatch, or rather, the motivation of D31201 is to help profile match by making call graphs similar on a high level.



https://github.com/llvm/llvm-project/pull/135152