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

Chandler Carruth chandlerc at google.com
Wed Aug 20 01:49:51 PDT 2014


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, 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140820/804498d3/attachment.html>


More information about the llvm-commits mailing list