Messages in this thread | | | Subject | Re: GCC 3.4 and broken inlining. | From | Alexandre Oliva <> | Date | 14 Jul 2004 00:00:54 -0300 |
| |
On Jul 11, 2004, Andi Kleen <ak@muc.de> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |