This is the mail archive of the
mailing list for the GCC project.
Re: On inlining in C++
- From: Thomas Kunert <kunert at physik dot tu-dresden dot de>
- To: Mike Stump <mrs at apple dot com>
- Cc: Joe Buck <jbuck at synopsys dot com>, Gabriel Dos Reis <gdr at integrable-solutions dot net>, gcc at gcc dot gnu dot org
- Date: Tue, 05 Aug 2003 09:37:06 +0200
- Subject: Re: On inlining in C++
- References: <8380D110-C708-11D7-A9D4-003065A77310@apple.com>
Mike Stump wrote:
On Monday, August 4, 2003, at 09:31 AM, Joe Buck wrote:
On Mon, Aug 04, 2003 at 03:06:43PM +0200, Gabriel Dos Reis wrote:
Give C++ "inline" its original and obvious meaning
Gabriel Dos Reis <gdr@integrable-solutions>
This is a complete waste of time. inlining is an optimization.
Optimizations are always subject to improvement. Therefore, inlining is
subject to improvement.
Removing the optimizer from inlining isn't where we are going, it just
isn't going to happen, ever, get over it.
What isn't a waste of time, would be to point out a case where the
optimizer gets it wrong, and explain what would be better, and then we
can retune the optimizer to be _better_ without that being at the
expense of other code. We already knew that some of the heuristics are
probably wrong for C. If people want, we can bump up the numbers a ton
for the heuristic for things marked with inline (or whatever else anyone
would like) and then wait for the bug reports that said we went too far,
and then bump them back down some...
It would be good if we could sign up lots of people to benchmark their
favorite programs as we tune it around, and give timely feedback on them
so that we know how things are being impacted.
As a C++ programmer I would like to ask you to retain a mechanism to tell
the compiler "Inline at least everything I marked as inline." Currently,
this mechanism is -finline-limit=1000000.
Correct decisions about efficient inlining depend on many parameters the
compiler does not know, e.g.
- How much time takes one call of the function. This time in general depends
on the actual parameters and cannot be guessed by the compiler.
- How much total time does the code spent in the function. If this time is
only a few micro seconds, there is absolutely no point in inlining.
- From how many places the function is being called throughout the program.
- How often the function is called from a certain position.
The programmer has the complete picture. He has an idea about the actual
parameters passed to the function. He can actually measure the time.
He knows if some function is critical or not.
Maybe someday in the distant future compilers are smart enough to find out
these things. But currently I strongly prefer to control inlining myself,
because in most cases I know better. The compiler should be allowed to
overrule my decision only if it can prove me wrong.