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

[Joe Buck <jbuck at synopsys dot com>]

On Sat, Mar 15, 2003 at 02:20:42PM -0500, Robert Dewar wrote:
> > And why not?  If I add the "inline" keyword, I do it for a good reason (I
> > want the function inlined).
> 
> even if it makes your program run slower? I think most programmers would
> answer no .. they write inline to speed up their program, not slow it down
> and make it bigger and slower :-)

My take on the matter: if the programmer said "inline", gcc should honor
this directive except in situations where doing so is not possible (e.g.
the function is invoked as a virtual call or via a pointer, or it's
recursive), or there is some reason that correctly inlining the function
would be extremely difficult to implement (example: the order in which
the functions and declarations appear require too much lookahead, or
non-inline declarations are followed by uses and then only later by
inline definitions, as can occur in C++).  If the resulting code is bigger
and slower, make it bigger and slower, but let's get real: gcc's current
heuristics are too stupid to have any idea whether inling a call will
make the program bigger and slower or not.  Given that, we shouldn't be
punishing programmers who measure carefully in an effort to baby-sit those
who use "inline" without thinking.

I am well aware that the standard states that "inline" is advisory, 
but in a high-quality implementation this should be taken to just cover
the cases where inlining the call is not possible or is extremely difficult.
If the compiler can honor the user's request without jumping through
too many hoops, it should do so.