Re: Inlining (was: GCC 3.3 release criteria)

[Matt Austern <austern at apple dot com>]

On Monday, February 24, 2003, at 07:20 PM, Tolga Dalman wrote:

> > We definitely don't want -fobey-inline to be the default: usually it's
> > better for the compiler to treat the inline keyword as a hint, and to
> > use its own heuristics to decide when to accept the hint.  But there 
> > are
> > cases, as you've found, when a flag like this is useful.
>
> this confuses me a bit. i always thought, that the "inline" keyword 
> would
> in any case force inlining, except for the -fno-inline flag activated.
> IMHO, the compiler should always obey user inlining, because the 
> compiler
> should trust the programmer when he uses an optional feature (such as 
> inline).
> for me, the question evolves: what does happen in -Os optimization? i 
> suppose,
> there isn't done any inline at all, not even explicitely "inline" 
> marked
> functions, no?

Some programmers have the expectation that the compiler will always 
inline
everything that's marked inline.  Other programmers very definitely do 
not
expect that, and write code where 'inline' is treated merely as a hint 
to the
compiler: marking a function 'inline' means you're telling the compiler 
that
you won't mind if it chooses to inline the function.

(Inline-as-hint is what the C++ Standard says, for what it's worth.  I 
don't know
the C99 standard as well.)

Empirically, treating 'inline' as a directive rather than a hint will 
make a lot
of programs much worse.  This isn't conjecture.  We did the measurement 
at
Apple.  -fobey-inline is occasionally useful, but making it the default 
would be
disastrous.

In the end I expect that more and more compilers will choose to ignore 
the
'inline' keyword entirely.  They'll treat it the same way as 
'register', and for
the same reason: a sufficiently clever optimizer has more information 
than
the programmer does, and can do a better job of knowing which functions
should be inlined.  Some optimizers are already good enough so that's 
true.
Our optimizer isn't (yet), but that's where we eventually want to be.

			--Matt