lkml.org 
[lkml]   [2004]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: GCC 3.4 and broken inlining.
From
Date
On Jul  8, 2004, Arjan van de Ven <arjanv@redhat.com> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.086 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site