On inlining in C++

[Richard Sandiford]

dewar@gnat.com (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"
poorly.

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
behaviour entirely.

Richard

PS. OK, so "principle of least surprise" was shorter ;)

[*] the one that Gaby quoted.