lkml.org 
[lkml]   [1998]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: 2.2.0 and egcs 1.1 was Re: Sorry, wrong gcc-version
Date
From
And lo, Andi Kleen saith unto me:
> On Mon, Oct 26, 1998 at 06:10:17AM +0100, Michael Harnois wrote:
> > Andi Kleen <ak@muc.de> writes:
> >
> > > I'm curious. Did you see any new to egcs 1.1 bug that was caused/went away
> > > with -fno-gcse ? I would expect global CSE to move a lot of code and cause
> > > locking problems etc. by this.
> >
> > The current problem with 2.1.126 and egcs-1.1a goes away (for me) by
> > adding -fno-inline-functions -fno-unroll-loops. I haven't yet
> > recompiled a few more times to see which of those is the actual cure.
>
> -finline-functions is a stupid idea to use with the lernel anyways.
> In Linux kernel source inline functions are explicitely marked as such
> (so that gcc inlines them even without -finline-functions), and for those
> that are not marked it is generally a loss. Some functions are explicitely
> tuned to _not_ inline the slow parts - if you use -finline-functions you
> defeat that goal. The same is true for -funroll-functionsc - loops that
> are worth unrolled are already unrolled, for the others it is usually a loss.

The code I've noticed uses macros when it wants stuff inlined, and uses
explicit inlining only as a way to write very long functions as multiple
functions (for readability) yet avoid the function call overhead. I
haven't seen explicit inlining anywhere else, and I've seen some huge
macros I'd give a compiler the option to not inline...but I didn't write
the code and I haven't read the whole kernel.

So, what makes it a win for all architectures to not suggest that the
compiler inline functions when it believes it would be faster, just
because a few functions ought not to be inlined and a few functions
which probably should be inlined are marked as such? I'd say tell the
compiler to inline and tell it what to not inline. That goes double for
loop unrolling; to mangle a metaphor, what's good for the goose is not
always good for the duck or the swan.


> It is quite possible that you are beaten by the assembler constraint problems
> discussed in other messages in this thread - they cause problems when the
> compiler has to manage lots of variables in only a few registers, and both
> loop unrolling and automatic inlining eat registers a lot.

If that's a problem, then the compiler should balance the spillage against
the potential gain (and the profiling data or hints, if any) and do a
reasonable approximation of the Right Thing(tm).


> One of the main performance advantages of Linux compared to bloated monsters
> like Solaris is that Linux generally uses simpler code which doesn't steal
> most of the L1 cache when you enter the kernel. Loop unrolling and automatic
> inlining cause code size increases which cancels that advantage.

When it's smart to unroll, you're trading off potential (even probable)
cache hits tomorrow for a definite gain today. When it's smart to inline,
you save the jumping and pushing and popping and don't even increase the
code size "experienced" unless a trip through the kernel calls that
inlined function multiple times from multiple different places.


Keith

--
"The avalanche has already started; |Linux: http://www.linuxhq.com |"Zooty,
it is too late for the pebbles to |KDE: http://www.kde.org | zoot
vote." Kosh, "Believers", Babylon 5 |Keith: kwrohrer@enteract.com | zoot!"
www.midwinter.com/lurk/lurker.html |http://www.enteract.com/~kwrohrer | --Rebo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.057 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site