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

[Bernd Schmidt <bernds at redhat dot com>]

On Sun, 16 Mar 2003, Robert Dewar wrote:

> > 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.
> 
> I have argued nothing of the kind, please reread what I have written. What
> I have said is that the compiler may have very good reasons in specific
> cases which result in a decision not to inline a given function. In fact
> you agree with this:
> 
> > within reason - I don't strongly object to not inlining
> > functions that call alloca, for example
> 
> What makes you think that I disagree and expect this to be done
> without reason?

Ok, maybe it wasn't clear what you are arguing for, or maybe I'm just dense.
Please spell it out for me - which kinds of reasons do you consider valid?

As far as I'm concerned, anything that can be documented clearly and
predictably (and preferrably does not significantly differ from established
behaviour in older versions of gcc) is fine.  "The function calls alloca"
is OK as an exception, "the compiler knows it will be slower with inline" is
not well-defined enough.

Even in some exceptional cases (like the alloca one) it may be preferrable
to actually perform inlining and warn the user about potential drawbacks if
"-Wall" is specified.  Otherwise you still need an extra always_inline
construct.


Bernd