Re: 2.2.0 and egcs 1.1 was Re: Sorry, wrong gcc-version

Andi Kleen (ak@muc.de)
Mon, 26 Oct 1998 07:55:34 +0100


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.

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.

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.

In short - never use anything above -O2 to compile the kernel.

-Andi

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