[lkml]   [2009]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact
On Fri, Jan 9, 2009 at 9:26 PM, Linus Torvalds
<> 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).


 \ /
  Last update: 2009-01-09 21:39    [W:0.443 / U:1.284 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site