• Approaches to the inliner blowing up There has been discussion throughout time about the inliner blowing up (e.g.[Inline] Unbounded inlining due to locally hot call sites · Issue #181821 · llvm/llvm-project · GitHub,Alwaysinliner time explosion with new pass manager · Issue #59126 · llvm/llvm-project · GitHub). • This is typically due to one of the fundamental flaws of the way we implement bottom up inlining without a global cost budget, which is that it’s very easy to inline small calls in a way that ends up being exponential, e.g. • all of the calls in the following individually seem fine to inline when inlining from@f, but in aggregate blow up compile time and binary size There have been a couple of proposals on limiting inlining.[Inline] Accumulate the cost of the inlined function to the new callsite by dianqk · Pull Request #111104 · llvm/llvm-project · GitHubadds extra cost on inlined call sites.[Inliner] Disable locally hot callsite heuristic for inlined calls by nikic · Pull Request #181827 · llvm/llvm-project · GitHubdisables a heuristic threshold increase for inlined call sites. • Talking to@chandlerc, here are some ideas bounced around: First of all, it’s nice to preserve inliner idempotency, meaning running the inliner multiple times shouldn’t cause more calls to be inlined.Having inlining budgets across multiple calls is the easiest way to break idempotency if the budget is only kept in memory and not recorded into the IR. • Having inlining budgets across multiple calls is the easiest way to break idempotency if the budget is only kept in memory and not recorded into the IR. • It’s also nice to not have inlining decisions differ depending on the order of processing call sites, which can easily happen with budgets.

Article Summaries:

  • There has been discussion throughout time about the inliner blowing up (e.g. [Inline] Unbounded inlining due to locally hot call sites · Issue #181821 · llvm/llvm-project · GitHub, Alwaysinliner time explosion with new pass manager · Issue #59126 · llvm/llvm-project · GitHub). This is typically due to one of the fundamental flaws of the way we implement bottom up inlining without a global cost budget, which is that it’s very easy to inline small calls in a way that ends up being exponential, e.g. all of the calls in the following individually seem fine to inline when inlining from @f , but in

Sources: