Messages in this thread |  | | | Date | Mon, 26 Oct 1998 07:55:34 +0100 | | From | Andi Kleen <> | | Subject | Re: 2.2.0 and egcs 1.1 was Re: Sorry, wrong gcc-version |
| |
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/
|  |