Date:	Fri, 9 Jan 2009 21:37:13 +0100
From:	"Richard Guenther" <richard.guenther@...il.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Matthew Wilcox" <matthew@....cx>,
	"Andi Kleen" <andi@...stfloor.org>,
	"Dirk Hohndel" <hohndel@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>, "Ingo Molnar" <mingo@...e.hu>,
	"jim owens" <jowens@...com>,
	"Chris Mason" <chris.mason@...cle.com>,
	"Peter Zijlstra" <peterz@...radead.org>,
	"Steven Rostedt" <rostedt@...dmis.org>, paulmck@...ux.vnet.ibm.com,
	"Gregory Haskins" <ghaskins@...ell.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Nick Piggin" <npiggin@...e.de>,
	"Peter Morreale" <pmorreale@...ell.com>,
	"Sven Dietrich" <SDietrich@...ell.com>, jh@...e.cz
Subject: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact

On Fri, Jan 9, 2009 at 9:26 PM, Linus Torvalds
<torvalds@...ux-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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists