This is the mail archive of the
mailing list for the GCC project.
Re: On inlining in C++
- From: Mike Stump <mrs at apple dot com>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: Joe Buck <jbuck at synopsys dot com>, gcc at gcc dot gnu dot org
- Date: Tue, 5 Aug 2003 12:10:07 -0700
- Subject: Re: On inlining in C++
On Tuesday, August 5, 2003, at 01:25 AM, Gabriel Dos Reis wrote:
If people want, we can bump up the numbers
It it a matter of bumping numbers.
Ok, submit numbers for a testcase, before the change, a suggested
change, and numbers after... I think it is productive if we bump up
the number, not to 4233153983 from a previous of 300, but rather to
another number such that your testcase gets 95% of the benefit you see
to switching to a number like 4233153983 and for all lower numbers, the
you get <95% of the improvement.
So, instead of picking 3000, as the best, we pick 393, as then we get
most of the benefit, maybe not all, but most. I'd ask that the
testcase be real code, or abstracted from real code, not purely
invented to move the numbers.
Also, any such change should be weighed against real code, SPEC, a
boost or something like it benchmark and so on... plus anything else
people would like to run against.
For example, some numbers were put in for C++ because of odd template
code, where everything is marked inline but, we don't want to explode
things, but these same number probably hurt C inlining performance.
I've not seen too many people complaining that C inlines too much (well
other than indirectly about -O3, which we can discount as a factor for
some types of changes), and have seen lots of people complaining that C
inlines too little, so, bumping up some of the numbers for C, easily
Likewise, even for C++, we should be happy to experiment some with the
numbers and collect feedback on those experiments and _then_ make an
informed choice on what the numbers are.
My hope is that we can globally improve the choices the compiler makes
by default, not just for any one testcase.
I'd rather have a debate that tuning the defaults for KDE speed is
slightly more important than tuning for raw SPEC speed, as SPEC people
have ways to get the right numbers into the compiler. Or that tuning
for boost is more important than tuning for <name of some other random
Also, we could discuss, should this tuning parameter be used in this
case or should this other parameter be used (or invented), for example,
for methods contained textually inside a class, should we use the same
parameter as functions marked inline in C or... Here is where I'd love
If you are the only one to submit numbers, then you might be able to
move any of the numbers anyway you want. If others don't like such a
movement, sooner or later someone is going to have to submit numbers,
and then we might have to revisit the issue.
I don't want you to feel like you are loosing, or that the compiler
isn't doing the best that it can. I'd rather empower you to tell us
the performance you see, and ask for a change of default, or ask for
improvements in the underlying algorithms; then based upon all that we
hear from everyone, the maintainers are going to have to just make the
best choices they can. The process should be open, honest and
reflective of the needs of users.
If that sounds reasonable, let's do it, if it doesn't, ignore me... :-)