[llvm-dev] [RFC] Add a module inliner

[Wenlei He via llvm-dev]

This is a topic that has been discussed a few times in the past. Currently CGSCC inliner doesn’t use a size/growth cap, so the value of call site prioritization is questionable as we’re going to inline everything deemed beneficial anyways. But prioritization would be helpful for top-down inliner that needs a size/growth cap.

Under Sample PGO, we now have a top-down inliner in sample loader already to handle most of the hot inlining (https://reviews.llvm.org/D70655, https://reviews.llvm.org/D82919). Sample loader is a module pass, so the inliner there is module inliner too. And with the new CSSPGO (https://lists.llvm.org/pipermail/llvm-dev/2020-August/144101.html), we’ve changed to use a call site prioritized top-down inliner for sample loader as the inlining there is no longer limited to inline replay (https://reviews.llvm.org/D94001). The sample loader inliner is probably closer to what you’re planning to do, but such top-down call site prioritization would be most effective when context-sensitive profile is available so inliner can do proper specialization along different inline context.

+ at Hongtao Yu<mailto:hoy at fb.com> @Lei Wang<mailto:wlei at fb.com>

Thanks,
Wenlei

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of David Blaikie via llvm-dev <llvm-dev at lists.llvm.org>
Date: Monday, August 30, 2021 at 9:52 AM
To: Liqiang Tao <taolq926 at gmail.com>, Chandler Carruth <chandlerc at gmail.com>, Arthur Eubanks <aeubanks at google.com>, David Li <davidxl at google.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] [RFC] Add a module inliner
+a couple of folks who might have some thoughts/ideas here

On Tue, Aug 24, 2021 at 8:57 AM Liqiang Tao via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

In my GSoC 2021, my goal is to evaluate the value of different callsite visiting orderings, which is inspired by paper[1][2]. I've already enabled doing such an exploration within the constraints of the current SCC inliner (https://reviews.llvm.org/D104028<https://reviews.llvm.org/D104028>). Exploring more advanced callsite orderings is not possible with the current SCC inliner. The current SCC inliner runs on each SCC in a bottom-up traversal, which means that the inline order is limited to a bottom-up order.

To address this limitation, I would like to add a module inliner, which processes all call sites in a given module at a time instead of a given SCC. This gives us flexibility on the order in which we process call sites.

The module inliner would be disabled by default, to minimize code churn to the existing codebase and make it easier to remove it. Also, to avoid unnecessary abstractions, which would complicate the existing codebase, some code is copied from SCC inliner. Lastly, to foster collaboration, I would propose landing it in trunk rather than a branch.

Best wishes,

Liqiang Tao

---- [1] Aleksandar Prokopec, Gilles Duboscq, David Leopoldseder, and Thomas Würthinger. 2019. An optimization-driven incremental inline substitution algorithm for just-in-time compilers. In Proceedings of the 2019 IEEE/ACM International Symposium on Code Generation and Optimization (CGO 2019). [2] Dhruva R. Chakrabarti and Shin-Ming Liu. 2006. Inline Analysis: Beyond Selection Heuristics. In Proceedings of the International Symposium on Code Generation and Optimization (CGO '06).
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210830/7988d924/attachment.html>