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]
Other format: [Raw text]

On inlining in C++ with unit-at-a-time code


> On Tue, 5 Aug 2003, Joe Buck wrote:
> > Fine.  Then accept Gaby's proposal as a stopgap solution until we can
> > produce an automatic inliner that is any good.
> 
> I tried to keep out of this, but -- let's see numbers, please.
> 
> Jan and me have performed relatively extensive tests in June when Jan
> was working on the improved inliner, and also Richard Guenther has been
> running extensive tests with his applications.
Hi,
Concerning the inlining limits, I believe we should increase them.  We
did some testing with Andreas and the SPEC scores gradualy improve with
inline limit increasing (that wasn't the case of old inlining size
estimates).  The sizes around 150 seems to give best performance/code
size ratio.  For x86-64 the peak is slightly earlier, for i386 slightly
later reflecting large function call costs of i386.

Situation seems to be the same for C++ programs I tested too (your
benchmark suite and similar).  For functions marked explicitely as
inline I would like the limit to see even higher limit if C++
programming style allows us to do, this needs more testing, but I think
the values around 500 would be OK.

Unforutnately we can't do the change on mainline yet as old inlining
heuristics is still active for -O2 and will result in memory bombs then.
I hope we can enable unit-at-a-time at -O2 by default and solve the
problem in easy way.  In SuSE we are experimentally building the
distribution with it and now all problems directly attributable to
unit-at-a-time seems to be gone.  I will send more detailed summary
sometime next week as this week I am on the trip.  Of course few
remaining patches I sent needs to get in first but Mark seems to be
doing great job on reviewing them.

So please if you complain about the inlining decisions, can you, please
try -O2 -funit-at-a-time --param max-insns-inline-single=500 --param
max-insns-inline-auto=150 and send me a testcases in case it won't do
what do you want? (if it inlines way too much, please try to lower the
inline-single limit to 150 again, I didn't do much testing with
inline-single limit set so high)

With this settings I believe we should be able to quite consistently
outperform the old inlining heuiristics of 2.95 both compile time-memory
wise and code quality wise.

Honza


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