This is the mail archive of the
mailing list for the GCC project.
Re: On inlining in C++
- From: Richard Sandiford <rsandifo at redhat dot com>
- To: dewar at gnat dot com (Robert Dewar)
- Cc: gdr at integrable-solutions dot net, jbuck at synopsys dot com, gcc at gcc dot gnu dot org
- Date: 05 Aug 2003 08:39:39 +0100
- Subject: Re: On inlining in C++
- References: <20030804163548.93772F2D7E@nile.gnat.com>
firstname.lastname@example.org (Robert Dewar) writes:
> > 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.
I'd have thought the burden was (almost entirely) on the people
defending g++'s current behaviour. Suppose that, as an experiment,
someone changes g++ to interpret inline in the "traditional"[*] way.
And then someone shows that this leads to worse performance for program
X on target Y. I don't think we can then say that the compiler is right
to behave is it does now. Perhaps whoever wrote program X didn't care
about the performance on target Y, or perhaps s/he simply used "inline"
Both are possible, and it's not the sort of thing you're going to get
from a simple statistical analysis (said in response to: "we need more
data", from another message).
So (IMO) if g++ is going to ignore inline requests for "inlineable"
functions, the data in favour of that should be overwhelming. It's a
bit worrying that g++ is already doing this and that no-one seems to
have a large body of existing data to justify it.
Even if we change gcc in the way that Gaby suggests, we could still
provide the existing behaviour as a flag. A sort of restricted
-finline-functions. It's not like we have to lose the existing
PS. OK, so "principle of least surprise" was shorter ;)
[*] the one that Gaby quoted.