This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Inlining (was: GCC 3.3 release criteria)
On Tue, 25 Feb 2003 09:59:52 -0800 Matt Austern <austern at apple dot com> wrote:
> 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.
>
yeah, but i'm not able to say "definitively: don't compile this function as
inlined one!", neither saying "inline" nor saying "don't inline" is then
possible.
> (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.
>
i understand. IMHO, gcc _should_ deprecate the ISO-C qualifiers inline and
register then , since they are not usable in an appropriate way. doing so, gcc
could "educate" a programmer _not_ to use these keywords, even though they're
defined in the standard.
> 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.
but that's not the point: from my point of view as "user", i want to be able to
disable inlining entirely except for those functions i explicitely mark (via
-Os for example). or the other way round: i want to inline everything (with a
certain threshold of course), except for a few function that never should be
inlined.
i believe, the standard inlining algorithms are very good, but gcc (rather the
standard itself) makes finetuning impossible. please correct me, if i was wrong.
brg,
Tolga.