Re: GCC 3.4 and broken inlining.

[Alexandre Oliva]

On Jul  9, 2004, Nigel Cunningham <ncunningham@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/