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

[Geoff Keating <geoffk at geoffk dot org>]

Joe Buck <jbuck at synopsys dot com> writes:

> dewar at gnat dot com (Robert Dewar) writes:
> > |> It's dubious even for a "state of the art optimizing compiler" The programmer
> > |> often knows better than any compiler what should be inlined.
> 
> On Fri, Mar 14, 2003 at 09:00:39PM +0100, Andreas Schwab wrote:
> > The same has been said about register ....
> 
> There are important differences.
> 
> In the case of the kernel programmers, they most emphatically *do* know
> that a function marked inline must be inline, because there are points in
> the kernel where there is not even a stack.  In such cases, the decision
> about whether to do inlining simply cannot be left to the compiler.

This is true for some functions marked inline in the kernel, but not
for all of them; some are marked inline just for speed.  That's why a
global flag like -fobey-inline is a bad idea, and the attribute that
we have now is a good idea.

> As for other cases, gcc's current inlining heuristics aren't very good, so
> your analogy to the "register" keyword does hold up.  Ten or 15 years ago,
> the state of the art of compilers was such that programmer use of the
> "register" keyword yielded substantially better code; now this is no
> longer true.  Maybe a few years from now, gcc will make better decisions
> about inlining.  But at the moment, the programmers I work with carefully
> study gprof or Quantify reports, determine which functions need to be
> inlined, add the "inline" keyword, and scream when gcc thinks it knows
> better (hint: it doesn't).

That's an argument that GCC should give more weight to the inline
keyword now, but not an argument that GCC should promise to obey it
slavishly in the future.

-- 
- Geoffrey Keating <geoffk at geoffk dot org>