Re: GCC 3.4 and broken inlining.

[Alexandre Oliva]

On Jul  8, 2004, Arjan van de Ven <arjanv@xxxxxxxxxx> wrote:

> the problem I've seen is that when gcc doesn't honor normal inline, it will
> often error out if you always inline....

Because the always_inline was designed to mark functions that *must*
be inlined otherwise the program breaks (e.g., early dynamic loader
code where you still can't do function calls), not as an
`I'd-really-like-this-to-be-inlined-dammit' flag.

We could add another attribute/keyword/whatever to give a stronger
inline hint, but that would still leave room for the compiler to
decide it can't inline the function for whatever reason.  So you have
to know what to demand from the compiler:
inline-or-fail-because-there's-no-point-otherwise (attribute
always_inline) or inline-if-it-makes-the-program-faster (inline
keyword).  The latter is obviously based on heuristics, so it
sometimes gets things wrong, especially when inlining would enable a
lot of simplification that the compiler can't foresee without actually
doing the work and somehow backtracking if it turns out to not be
profitable (which would still be a guess).

-- 
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/