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

Linus Torvalds torvalds@transmeta.com
Mon Dec 10 13:59:00 GMT 2001


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



More information about the Gcc mailing list