Messages in this thread | | | Subject | Re: GCC 3.4 and broken inlining. | From | Alexandre Oliva <> | Date | 10 Jul 2004 18:33:40 -0300 |
| |
On Jul 9, 2004, Nigel Cunningham <ncunningham@linuxmail.org> wrote:
> I do think that functions being declared inline when they can't be > inlined is wrong
The problem is not when they can or cannot be inlined. The inline keyword has nothing to do with that. It's a hint to the compiler, that means that inlining the function is likely to be profitable. But, like the `register' keyword, it's just a hint. And, unlike the `register' keyword, it doesn't make certain operations on objects marked with it ill-formed (e.g., you can't take the address of an register variable, but you can take the address of an inline function).
The issue with inlining that makes it important for the compiler to have something to say on the decision is that several aspects of the profit from expanding the function inline is often machine-dependent. It depends on the ABI (calling conventions), on how slow call instructions are, on how important instruction cache hits are, etc. Sure enough, GCC doesn't take all of this into account, so its heuristics sometimes get it wrong. But it's getting better.
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 inline keyword covers the may-inline'case. The absence of the inline keyword implies `should-not-inline', and attribute noinline covers must-not-inline. should-inline can't be expressed today, and if may-inline doesn't get the desired effect, you may feel tempted to abuse always_inline, but I suggest you to do so using a different macro, such that, if GCC ever introduces a new attribute that's a stronger hint to inlining that doesn't error out if it can't be done, you can easily switch to it.
-- 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/
| |