This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]