[PATCH] D121862: [ProfSampleLoader] When disable-sample-loader-inlining is true, merge profiles of inlined instances to outlining versions.

[Hongtao Yu via Phabricator via llvm-commits]

hoy added a comment.

Thanks for sharing more about the context and the background, @kazu

> I enabled the cost-benefit analysis in early 2021 for instrumentation FDO. It gives us performance gains by inlining big but very hot call sites that would be rejected by the simple size-based threshold.

How about the build time? We've encountered dramatic build time increase due to giant functions as a result of aggressive AutoFDO inlining.

> So, I am wondering if we could intelligently tune down the sample loader inliner -- inlining context-sensitive callees in the sample loader inliner and leaving the rest to the SCC inliner.

I'm trying to find the theory behind this. The two inliner behaves differently due to their style, i.e, top-down vs bottom-up. Regardless of context-sensitivity, shifting inlining from one to the other may create different inlining patterns, and I didn't find an easy way to tell which is better. Please let me know your insight on this. We are trying to make the whole inlining process perform uniformly (for now trying to shift as much inlining towards the top-down sample loader inliner) to focus on tuning an inlining model towards one inliner. We found it more complicated in LTO mode where prelink CGSCC inlining could affect post-link sample loader inlining in an unexpected way, i.e, increasing candidate size and breaking the pre-existing calling context in the profile. This makes it harder to tune the heuristics for the sample loader. We tried to turn off the prelink cgscc inliner and saw some size wins but neutral perf. We will likely do more investigation in this direction.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121862/new/

https://reviews.llvm.org/D121862