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

[Hal Finkel]

----- 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...]

 -Hal

> and might allow us to be more
> aggressive in certain circumstances than we are without adverse
> effects. It would also improve code size in specific cases that seem
> useful, just not pressing.

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory