This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Inlining heuristics for C++


Mark Mitchell <mark@codesourcery.com> writes:

> --On Monday, July 09, 2001 09:46:59 PM -0400 Daniel Berlin
> <dan@cgsoftware.com> wrote:
> 
>> Right now, they are horrific.
> 
> Hey, thanks a lot. :-)  They are, actually, the same ones we had in
> the RTL inliner, just about -- except that we can inline so much more!
> 
> I think your ideas are reasonable.  Nathan Sidwell has been thinking
> about these issues, too; you should coordinate with him to try to
> get some decent ideas and some decent measurements.
> 
> One long-term challenge is that we would like to inline when somehow
> that allows major simplifications.  For example, if there is a giant
> function involving tons of calcuation, but we know that the argument
> is `3', and that means we can fold all the calculations, then we
> should do the inlining, even if the inlined function is nominally
> giant.  I have no idea how to do this, though.  It's probably not worth
> bothering about.

The whole method defaulting to inline thing also explains why v3 was
hit so hard.
It's mostly headers, and thus, all the code is readily available to be
inlined, into any translation unit.

If I -fno-default-inline, i can't get 15k insns to appear on the
example. even at --param max-code-growth=500

 TOTAL                 :   8.10 ....
zsh: exit 1     ./cc1plus --param max-code-growth=500 -O3 -fno-default-inline test3.ii
./cc1plus --param max-code-growth=500 -O3 -fno-default-inline test3.ii
 8.10s user  ...

So definitely, methods were being all marked inline and inlined.

This is fine, as long as we control code growth.
As the timing vs what i posted earlier shows, we don't save more than a second default-inline
on or off with a normal code growth control factor.
(%:/buildspace/egcs/build/gcc)- time  ./cc1plus -O3 -fno-default-inline test3.ii 2>/dev/null
./cc1plus -O3 -fno-default-inline test3.ii 2> /dev/null  8.12s user 0.28s system 100% cpu 8.398 total
(dberlin@debian)(241/vc)(03:28am:07/10/01)-
(%:/buildspace/egcs/build/gcc)- time  ./cc1plus -O3 test3.ii 2>/dev/null
./cc1plus -O3 test3.ii 2> /dev/null  8.12s user 0.27s system 99% cpu 8.471 total
(dberlin@debian)(242/vc)(03:28am:07/10/01)-
(%:/buildspace/egcs/build/gcc)-


It's only what we have now that makes it such a problem.

In fact, i don't have a vote, but if i did, i'd vote for leaving
flag_default_inline as is, and just installing the new heuristic i'll
post a patch for.

We should get better code overall that way, and never worse.
--Dan

> 
> -- 
> Mark Mitchell                mark@codesourcery.com
> CodeSourcery, LLC            http://www.codesourcery.com

-- 
"What's another word for Thesaurus?
"-Steven Wright


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]