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

    \
     
     \ /
      Last update: 2005-03-22 14:04    [W:0.022 / U:60.660 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site