This is the mail archive of the
mailing list for the GCC project.
Re: On inlining in C++
- From: Joe Buck <jbuck at synopsys dot com>
- To: Robert Dewar <dewar at gnat dot com>
- Cc: gdr at integrable-solutions dot net, gcc at gcc dot gnu dot org
- Date: Mon, 4 Aug 2003 10:33:55 -0700
- Subject: Re: On inlining in C++
- References: <20030804163548.93772F2D7E@nile.gnat.com>
On Mon, Aug 04, 2003 at 12:35:48PM -0400, Robert Dewar wrote:
> > Excellent article. I think that anyone who wishes to oppose the argument
> > should be asked to demonstrate that we can get better quality of results
> > by deviating from the simple approach Gaby describes; philosophical
> > arguments should not suffice.
> Well there is a burden of demonstration on both sides I would say, in terms
> of showing behavior on actual code.
Don't forget that the biggest complaint we have about GCC is how slow the
compiler is. Ignoring or partially ignoring "inline", and doing analysis
instead, costs time.
I suggest resolving this argument by doing an experiment.
Option 1: a version of GNU C++ that
* honors the "inline" keyword in all situations where the compiler is
capable of inlining the call
* does the same for functions defined in the class body
* when -Winline is given, issues a warning and explanation about why
a call is not inlined
* avoids computing any metrics related to inlining decisions (unless -O3)
Option 2: a version of GNU C++ that uses the smartest heuristics that the
"ignore inline" advocates can come up with.
Part of the work for the experiment is to have a libstdc++ that is
as nearly clean with respect to -Winline (without resorting to suppressing
messages from system headers) as it can be made.
The switch between the two modes can be done by a flag, an ifdef,
whatever. I don't care, because I suspect we'll wind up shipping only one
Now, build a lot of C++ code with -O2 for both options. Measure compiler
speed as well as speed and space of the final code. If option 2 is
consistently better, I surrender. If option 2 is better only for one or
two programs, and it turns out that these programs use "inline" in
inappropriate ways, then the programs should be fixed.
My prediction is that option 1 will be better by every measure (though the
compile time difference may be small).