Re: GCC 3.4 and broken inlining.

[Alexandre Oliva]

On Jul 11, 2004, Andi Kleen <ak@xxxxxx> wrote:

>> Meanwhile, you should probably distinguish between must-inline,
>> should-inline, may-inline, should-not-inline and must-not-inline
>> functions.  Attribute always_inline covers the must-inline case; the

> You're asking us to do a lot of work just to work around compiler bugs?

Not asking.  Just suggesting that you make your request to the
compiler clearer.  This may enable the compiler to do a better job for
you.  You don't have to switch it all at once.  Keep inline as
always_inline, if you like, and downgrade other inline requests as you
see fit.

Of course having inline expand to something containing always_inline
will take a bit of preprocessor hackery to get other macros to expand
to the inline keyword without this attribute.

> I can see the point of having must-inline - that's so rare that
> it can be declared by hand. May inline is also done, except
> for a few misguided people who use -O3. should not inline seems
> like overkill.

`should not inline' is the default: a function not declared as inline
won't be inlined unless several conditions are met, e.g., compiling
with -O3 and/or -finline-all-functions.  It's the other cases to tune
inlining directives that would be useful.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/