Re: Optimizations on long long multiply/divide on PowerPC32 don'twork

[Linus Torvalds <torvalds at transmeta dot com>]

On Mon, 10 Dec 2001, Richard Henderson wrote:
> > Read my email again. Read the part about why we do not want to have the
> > slow crap routines, when most likely the user really _wanted_ a unsigned
> > shift in the first place.
>
> As stated, that sounds reasonable.  Just so long as it's not
> automatically considered a compiler bug that you run in to
> these things from time to time.

Oh, agreed.  The kernel makes this a conscious choice, and makes it own
routines for when they are needed.

As an example of where the kernel does its own "mini-libgcc" is the fact
that the kernel actually _does_ end up needing a 64-bit divide, but the
kernel happily gets by with the (often much faster) 64:32 version.

Now, gcc itself could be smart enough to notice when we do a 64:32 divide,
but it historically hasn't, and I bet it still doesn't. So Linux has it's
own per-architecture "do_div()" routines rather than letting gcc mess up a
perfectly simple 64:32 divide into a much more complicated 64:64 divide.

So it's a bit of extra work, but it's really not all that much (I do not
think we've needed to do _anything_ in this area for the last few years
except for some cleanups).

And as you've noticed, the problems really often _do_ end up being gcc
optimization issues..

(The kernel has historically also noticed some cases where gcc was silly
enough to not optimize away compile-time constant "switch" statements etc,
so I think that on the whole we've found mostly real deficiencies in the
compiler, and quite few cases where we needed to change the kernel)

			Linus