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

[Chandler Carruth]

On Wed, Aug 20, 2014 at 1:58 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "Chandler Carruth" <chandlerc at google.com>
> > To: "Hal Finkel" <hfinkel at anl.gov>
> > Cc: "Xinliang David Li" <xinliangli at gmail.com>, "Jiangning Liu" <
> Jiangning.Liu at arm.com>, "LLVM Commits"
> > <llvm-commits at cs.uiuc.edu>
> > Sent: Wednesday, August 20, 2014 3:49:51 AM
> > Subject: Re: [PATCHES] A module inliner pass with a greedy call site
> queue
> >
> >
> >
> >
> >
> > On Wed, Aug 20, 2014 at 1:36 AM, Hal Finkel < hfinkel at anl.gov >
> > wrote:
> >
> >
> >
> >
> > > Also, neither Duncan nor I were able to find copious examples where
> > > the lack of such a threshold caused runaway bad inlining decisions
> > > *and* this had a gross impact on overall performance. The current
> > > worst impact I've found are massive global constructor functions in
> > > Chromium which have template-expanded calls to 1000s of small
> > > functions inlined into them with no performance benefit and
> > > non-trivial code size growth. But so far, this hasn't even been
> > > found to be the high order bit in Chromium for either performance
> > > or
> > > code size, so.... :: shrug ::
> >
> > So the conclusion is that we might not need a limit at all? Sounds
> > good to me.
> > No, my conclusion is that it isn't worth hacking in a limit to solve
> > an immediate, pressing problem. I still think that a limit such as
> > the one I describe would be useful,
>
> You're referring to the fixed-point iteration scheme you outlined? [I'm
> not sure I'd call that a "limit", but...]


The idea is to incorporate a total size growth of the caller limit. Then
you inline up to that point, re-run the optimization passes to let them
bring you back under that limit if possible. Rinse, repeat. It allows the
inliner to keep inlining as long as the post-inlined code keeps optimizing
away, but enforces a total growth cap when the code *doesn't* optimize away.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140820/65a97a59/attachment.html>