Re: -fobey-inline (was Re: gcc and inlining)

[Bernd Schmidt <bernds at redhat dot com>]

On Sat, 15 Mar 2003, Robert Dewar wrote:

> > Well, you'd assume the person who adds "inline" has done measurements or
> > looked at the generated assembly.
> 
> I think you would be entirely wrong. Certainly in Ada, I can promise you
> that (this is looking at 20 years of extensive experience with the use
> of pragma Inline) most Ada programmers don't know enough to look at the
> assembly language, and very few have done measurements.

Let me remind you that we are discussing the effects of a change in
behaviour of our C compiler.  What Ada programmers do or don't do may be
influenced by the behaviour of Ada compilers and might therefore not be
entirely relevant.

And yes, you can shoot yourself in the foot by adding inline to the wrong
function.  However, unlike a heuristic inside a compiler, a human can
recognize, fix, and learn from a mistake.

It almost seems like this is turning into a question of interface design -
one philosophy ("nothing wrong with 'rm -rf /', let's do it.") vs. another
("Do you really want to empty the trash can?").  My idea of a useful
program is one that lets people who know what they are doing get on with
it.  If they don't have a clue - not our problem; garbage in, garbage out.

> Actually the task
> of doing measurements on a function by function basis is virtually
> impossible, since the choices interact, so if you have K functions
> that are possible candidates you would have to do 2**K measurements.

This kind of difficulty applies as well if you let the compiler make the
decision.  What makes you think it can do a better job?

> In practice the decision to use pragma Inline is based most typically
> on an assumption that the function is small, because the source is
> small and simple, and a knowledge that it is called frequently.

You've been arguing that the compiler will be smart enough to decide on
a case-by-case basis whether inlining is profitable.  To make such an
informed decision, you surely need information about function sizes and
execution frequencies, among several other things.  If this information
is available, then a mere hint becomes redundant [*] since you can deduce
the necessary conditions algorithmically.  OTOH, if such information is
not available, then the compiler really has no business second-guessing
the user.
In either case the only sane meaning for the "inline" keyword is to
always inline (within reason - I don't strongly object to not inlining
functions that call alloca, for example).  The alternative is, in the
first case, to have no effect, and in the second case, to have a random
effect - neither is useful.

So, our choice is whether we turn "inline" into an effective no-op and
replace its functionality with "always_inline" (causing performance
regressions and clutter in existing code), or whether we go back to our
previous behaviour which is expected by user code and in which "inline"
actually had a meaning.


Bernd

[*] Like "register".