[PATCHES] A module inliner pass with a greedy call site queue

Chandler Carruth chandlerc at google.com
Wed Aug 27 14:07:35 PDT 2014

On Wed, Aug 27, 2014 at 2:02 PM, Yin Ma <yinma at codeaurora.org> wrote:

> I understand iteratively applying inliner and other opts until converging
> or hit cut off
> may get better results. But indeed, it is very expensive.

The current LLVM inliner *is* such an iterative framework...

> For the application, such as
> chromium you mentioned, it may take hours to finish one round of
> compilation.
> We can have the complete iterative framework but 1 or 2 rounds may be a
> good
> heuristic as the default setup.

In the past when working on LLVM's existing iterative inlining framework we
needed many more rounds. The current system is designed to be iterative
while remaining efficient.

> I also know a little of chromium, in my opinion, having the iterative
> framework is not
> enough to bring up the performance because the critical path usually only
> touch a very
> small portion of the whole code and hot functions spread in many files. In
> order to
> ensure a certain cluster of functions to be inlined, we have to increase
> threshold to make
> sure all functions get inlined. As the result, the total size become much
> larger. So profile
> guided inlining should do better job here.

I'm not sure what you're trying to say here, but note that Chromium is only
one C++ project and I'm not sure it is even representative (it may be, I
just don't know). I usually look at a pretty wide range of C++ code bases
and patterns when considering something like the inliner, ranging from the
size of LLVM up to large C++ servers that contain many times the amount of
code Chromium does.

It is certainly not my experience that we have to increase thresholds to
make sure all functions get inlined for performance. It is more often that
*not* inlining cold functions is the key to performance, but even that is a
gross oversimplification.

> And for chromium, top-down approach should do better job than the current
> bottom up
> Approach especially with –Os option. There are so many C++ function calls.
> Because
> CallPenalty in the current SCC inliner is 25 and the threshold of –Os is
> very low, once a
> Function has one or two call to other function, the inlining will stop.
> This will leave a lot
> of functions not get inlined. And a lot of leaf functions are not hot
> functions. Bottom up
> approach can do better job for chromium.

This paragraph seems to contradict its first sentence. Certainly, the
reason why I am a strong proponent of bottom-up inlining is due to the
nature of call graphs formed by C++ code and its ability to optimize those
graphs in an efficient and effective manner.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140827/39d1de4f/attachment.html>

More information about the llvm-commits mailing list