Messages in this thread | | | Subject | Re: 2.2.0 and egcs 1.1 was Re: Sorry, wrong gcc-version | Date | Mon, 26 Oct 1998 01:53:40 -0600 (EST) | From | kwrohrer@ce ... |
| |
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/
| |