lkml.org 
[lkml]   [2009]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact
    On Fri, Jan 9, 2009 at 9:26 PM, Linus Torvalds
    <torvalds@linux-foundation.org> wrote:
    >
    >
    > On Fri, 9 Jan 2009, Richard Guenther wrote:
    >>
    >> This is a case where the improved IPA-CP (interprocedural constant
    >> propagation) of GCC 4.4 may help. In general GCC cannot say how a call
    >> argument may affect optimization if the function was inlined, so the
    >> size estimates are done with just looking at the function body, not the
    >> arguments (well, for GCC 4.4 this is not completely true, there is now
    >> some "heuristics"). With IPA-CP GCC will clone the function for the
    >> constant arguments, optimize it and eventually inline it if it is small
    >> enough. At the moment this happens only if all callers call the
    >> function with the same constant though (at least I think so).
    >
    > Ok, that's useless. The whole point is that everybody gives different -
    > but still constant - arguments.

    Btw, both GCC 4.3 and upcoming GCC 4.4 inline the bit-test. This is what I
    used as a testcase (to avoid the single-call and single-constant cases):

    #define BITS_PER_LONG 32
    static inline int constant_test_bit(int nr, const volatile unsigned long *addr)
    {
    return ((1UL << (nr % BITS_PER_LONG)) &
    (((unsigned long *)addr)[nr / BITS_PER_LONG])) != 0;
    }

    #define test_bit(nr, addr) \
    (__builtin_constant_p((nr)) \
    ? constant_test_bit((nr), (addr)) \
    : variable_test_bit((nr), (addr)))

    int foo(unsigned long *addr)
    {
    return test_bit (5, addr);
    }

    int bar(unsigned long *addr)
    {
    return test_bit (6, addr);
    }

    at -Os even.

    >> The above is definitely one case where using a macro or forced inlining is
    >> a better idea than to trust a compiler to figure out that it can optimize the
    >> function to a size suitable for inlining if called with a constant parameter.
    >
    > .. and forced inlining is what we default to. But that's when "let's try
    > letting gcc optimize this" fails. And macros get really unreadable, really
    > quickly.

    As it happens to work with your simple case it may still apply for more
    complex (thus appearantly big) cases.

    >> > Maybe there was something else going on, and maybe Ingo's tests were off,
    >> > but this is an example of gcc not inlining WHEN WE TOLD IT TO, and when
    >> > the function was a single instruction.
    >> >
    >> > How can anybody possibly not consider that to be "stupid"?
    >>
    >> Because it's a hard problem, it's not stupid to fail here - you didn't tell the
    >> compiler the function optimizes!
    >
    > Well, actually we did. It's that "inline" there. That's how things used to
    > work. It's like "no". It means "no". It doesn't mean "yes, I really want
    > to s*ck your d*ck, but I'm just screaming no at the top of my lungs
    > because I think I should do so".
    >
    > See?

    See below.

    > And you do have to realize that Linux has been using gcc for a _loong_
    > while. You can talk all you want about how "inline" is just a hint, but
    > the fact is, it didn't use to be. gcc people _made_ it so, and are having
    > a damn hard time admitting that it's causing problems.

    We made it so 10 years ago.

    >> Experience tells us that people do not know better. Maybe the kernel is
    >> an exception here

    ^^^

    > Oh, I can well believe it.
    >
    > And I don't even think that kernel people get it right nearly enough, but
    > since for the kernel it can even be a _correctness_ issue, at least if we
    > get it wrong, everybody sees it.
    >
    > When _some_ compiler versions get it wrong, it's a disaster.

    Of course. If you use always_inline then it's even a compiler bug.

    >> But would you still want small functions be inlined even if they are not
    >> marked inline?
    >
    > If you can really tell that they are that small, yes.
    >
    >> They do - just constant arguments are obviously not used for optimizing
    >> before inlining. Otherwise you'd scream bloody murder at us for all the
    >> increase in compile-time ;)
    >
    > A large portion of that has gone away now that everybody uses ccache. And
    > if you only did it for functions that we _mark_ inline, it wouldn't even
    > be true. Because those are the ones that presumably really should be
    > inlined.
    >
    > So no, I don't believe you. You much too easily dismiss the fact that
    > we've explicitly marked these functions for inlining, and then you say
    > "but we were too stupid".
    >
    > If you cannot afford to do the real job, then trust the user. Don't guess.

    We're guessing way better than the average programmer. But if you are
    asking for a compiler option to disable guessing you can have it (you can
    already use #define inline always_inline and -fno-inline to get it).

    Richard.


    \
     
     \ /
      Last update: 2009-01-09 21:39    [W:0.029 / U:1.564 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site