Re: Optimizations on long long multiply/divide on PowerPC32 don't work

[Linus Torvalds <torvalds at transmeta dot com>]

In article <20011207164904.C16375@redhat.com> you write:
>On Fri, Dec 07, 2001 at 06:09:55PM -0600, Corey Minyard wrote:
>>   1) Add __divdi3 to the linux kernel.  I don't really think this is a 
>> good idea, and it shouldn't be required.
>
>Yes it should.  I've long considered it a bug that Linux
>didn't link against libgcc.

I'm sorry you feel that way, but what the gcc team has done to libgcc
has only made me _more_ convinced that not linking against that
steenking heap of *** is a really good idea.. 

Not linking against libgcc has found several problems in gcc.  Ranging
from missing totally obvious optimizations (and yes, I consider that a
_bug_, even though I know that some gcc people think that performance is
secondary), to horrible mis-features with exception handling. 

For example, it was the absense of libgcc that made us aware that the
kernel had to use magic (and largely undocumented) gcc command line
flags to make sure that gcc didn't try to insert its totally broken
exception handling code. 

Similarly, it is the lack of libgcc that was really helpful in pointing
out code where some people started using 64-bit arithmetic without
realizing just how slow it would be.  In fact, it was this very missing
__divdi3 thing that showed that you shouldn't try to do 64-bit divides,
when you can, by thinking about the problem for five minutes, do it
about a hundred times faster by just keeping a 32-bit index and offset
pair. 

Think about it this way: "libgcc" is the place where code goes to die. 
It is, by _design_, the place where gcc developers put the code that is
so cr*p that it cannot really be inlined.  Avoiding it is a _good_
thing, as it forces the kernel to step carefully around issues where gcc
has problems. 

The fact that gcc cannot do a 64-bit divide by a constant is a gcc
deficiency.  But it is NOT cause for including crap in the kernel. 

			Linus