From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25849 invoked by alias); 10 Dec 2001 08:56:04 -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 25155 invoked from network); 10 Dec 2001 08:54:46 -0000 Received: from unknown (HELO dot.cygnus.com) (205.180.230.224) by sources.redhat.com with SMTP; 10 Dec 2001 08:54:46 -0000 Received: (from rth@localhost) by dot.cygnus.com (8.11.2/8.11.2) id fBA8sjk23372; Mon, 10 Dec 2001 00:54:45 -0800 X-Authentication-Warning: dot.cygnus.com: rth set sender to rth@redhat.com using -f Date: Mon, 10 Dec 2001 01:15:00 -0000 From: Richard Henderson To: Linus Torvalds Cc: gcc@gcc.gnu.org Subject: Re: Optimizations on long long multiply/divide on PowerPC32 don't work Message-ID: <20011210005444.A23367@redhat.com> Mail-Followup-To: Richard Henderson , Linus Torvalds , gcc@gcc.gnu.org References: <3C115A53.2070206@acm.org> <20011207164904.C16375@redhat.com> <200112100658.fBA6wEh13767@penguin.transmeta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112100658.fBA6wEh13767@penguin.transmeta.com>; from torvalds@transmeta.com on Sun, Dec 09, 2001 at 10:58:14PM -0800 X-SW-Source: 2001-12/txt/msg00476.txt.bz2 On Sun, Dec 09, 2001 at 10:58:14PM -0800, Linus Torvalds wrote: > 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.. Ok, I'll bite -- what have we done to libgcc? > 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. Hogwash. Look at the example again. Signed division is not merely a shift. It's more like long long t1(long long v) { return (v + ((v < 0) ? 0x1ffLL : 0LL)) >> 9; } GCC knows how to do this. It will do this if the target supports all of these operations on 64 bit data types and it considers them to be cheap enough. r~