From: Linus Torvalds <torvalds@transmeta.com>
To: Richard Henderson <rth@redhat.com>
Cc: <gcc@gcc.gnu.org>
Subject: Re: Optimizations on long long multiply/divide on PowerPC32 don't work
Date: Mon, 10 Dec 2001 13:59:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.33.0112101342000.14693-100000@penguin.transmeta.com> (raw)
In-Reply-To: <20011210125611.A23739@redhat.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
next prev parent reply other threads:[~2001-12-10 21:52 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-07 16:08 Corey Minyard
2001-12-07 17:08 ` Richard Henderson
2001-12-07 17:40 ` Corey Minyard
2001-12-09 23:29 ` Linus Torvalds
2001-12-10 1:15 ` Richard Henderson
2001-12-10 1:24 ` Richard Henderson
2001-12-10 2:40 ` Franz Sirl
2001-12-10 9:21 ` Linus Torvalds
2001-12-10 10:59 ` Franz Sirl
2001-12-10 11:11 ` Linus Torvalds
2001-12-10 11:31 ` Gabriel Paubert
2001-12-10 17:58 ` Richard Henderson
2002-01-22 8:51 ` Franz Sirl
2002-01-22 12:04 ` Richard Henderson
2002-01-23 7:24 ` Gerald Pfeifer
2002-02-03 10:44 ` Franz Sirl
2001-12-10 9:15 ` Linus Torvalds
2001-12-10 13:03 ` Richard Henderson
2001-12-10 13:59 ` Linus Torvalds [this message]
2001-12-10 9:09 ` Paul Koning
2001-12-10 10:23 ` Linus Torvalds
2001-12-10 11:35 ` Optimizations on long long multiply/divide on PowerPC32 don't Joe Buck
2001-12-10 13:49 ` guerby
2001-12-10 14:08 ` Arnaud Charlet
2001-12-10 14:31 ` guerby
2001-12-10 9:09 ` Optimizations on long long multiply/divide on PowerPC32 don't work Christoph Hellwig
2001-12-07 18:28 mike stump
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.33.0112101342000.14693-100000@penguin.transmeta.com \
--to=torvalds@transmeta.com \
--cc=gcc@gcc.gnu.org \
--cc=rth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).