From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11154 invoked by alias); 10 Dec 2001 21:52:54 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 10012 invoked from network); 10 Dec 2001 21:51:36 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 10 Dec 2001 21:51:36 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id NAA06527; Mon, 10 Dec 2001 13:51:30 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma006497; Mon, 10 Dec 01 13:51:17 -0800 Received: from penguin.transmeta.com (penguin.transmeta.com [10.10.27.78]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id fBALpNS18003; Mon, 10 Dec 2001 13:51:23 -0800 (PST) Received: from localhost (torvalds@localhost) by penguin.transmeta.com (8.11.2/8.7.3) with ESMTP id fBALpLK14705; Mon, 10 Dec 2001 13:51:21 -0800 X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs Date: Mon, 10 Dec 2001 13:59:00 -0000 From: Linus Torvalds To: Richard Henderson cc: Subject: Re: Optimizations on long long multiply/divide on PowerPC32 don't work In-Reply-To: <20011210125611.A23739@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-12/txt/msg00554.txt.bz2 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