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)


On 14 Mar 2003, Geoff Keating wrote:

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

And why not?  If I add the "inline" keyword, I do it for a good reason (I
want the function inlined).  I don't see why the compiler has to make me
beg for it with "always_inline" when I've already made my intention clear.
If someone wants the compiler to guess for them, they should use
"-finline-functions" and hope someone fixes the heuristics.  The current
behaviour of "inline" is simply not predictable by the user, and hence it
is useless.


Bernd



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