This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -fobey-inline (was Re: gcc and inlining)
- From: Bernd Schmidt <bernds at redhat dot com>
- To: Geoff Keating <geoffk at geoffk dot org>
- Cc: Joe Buck <jbuck at synopsys dot com>, Robert Dewar <dewar at gnat dot com>,<gcc at gcc dot gnu dot org>
- Date: Sat, 15 Mar 2003 17:14:31 +0000 (GMT)
- Subject: 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