Messages in this thread | | | Subject | Re: GCC 3.4 and broken inlining. | From | Alexandre Oliva <> | Date | 10 Jul 2004 18:17:29 -0300 |
| |
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/
| |