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

[Kazu Hirata via llvm-dev]

Hi,

I think the idea is worth experimenting as long as the experiment does not
affect the production code very much.

We will most likely need a size cap.  I think we have yet to see whether we
can completely replace the profile-driven CGSCC inliner or use the
priority-based inliner for hot paths with low-priority call sites left for
the CGSCC inliner to process.

I am curious how many cases we can catch that are typical limitations of
the CGSCC inliner.  By that, I mean cases where, given A->B->C, inlining C
into B prevents B from being inlined into A, but inlining the original B
into A is more profitable.  Hot code with lukewarm slow paths are pretty
common like std::vector<T>::push_back, which occasionally allocates memory.

Kazu Hirata

On Mon, Aug 30, 2021 at 3:49 PM Wenlei He via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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 <hoy at fb.com> @Lei Wang <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> 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). 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
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> 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/20210901/4315c105/attachment-0001.html>