Inlining (was: GCC 3.3 release criteria)
Matt Austern
austern@apple.com
Tue Feb 25 18:01:00 GMT 2003
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
More information about the Gcc
mailing list