From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26012 invoked by alias); 10 Dec 2001 17:15:32 -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 25792 invoked from network); 10 Dec 2001 17:14:13 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 10 Dec 2001 17:14:13 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id JAA11902; Mon, 10 Dec 2001 09:14:08 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma011894; Mon, 10 Dec 01 09:13:56 -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 fBAHE0S13121; Mon, 10 Dec 2001 09:14:00 -0800 (PST) Received: from localhost (torvalds@localhost) by penguin.transmeta.com (8.11.2/8.7.3) with ESMTP id fBAH8Cx14215; Mon, 10 Dec 2001 09:08:12 -0800 X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs Date: Mon, 10 Dec 2001 09:21:00 -0000 From: Linus Torvalds To: Franz Sirl cc: Richard Henderson , Subject: Re: Optimizations on long long multiply/divide on PowerPC32 don't work In-Reply-To: <5.1.0.14.2.20011210112459.02481a90@mail.lauterbach.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-12/txt/msg00506.txt.bz2 On Mon, 10 Dec 2001, Franz Sirl wrote: > > Ah, now that is nice, I always wondered which codepath produced the > signeddivide64-by-exactlog2constant to shift conversion on x86, but > couldn't find anything in i386.md :-(. I'll try that one on 3.0.3pre and > see if the FAT FS compiles again (I wonder if my ashrdi3_nopower pattern > will get used then?). Which part of FAT-FS actually tries to do a signed division? I have a VERY strong suspicion that any filesystem that wants to divide by 512 is really just getting a sector number, and the division should not be signed in the first place. > Despite the missing GCC optimization, I always wondered if the FAT FS > really relies the roundup happening with a signed divide, or if we could > simply replace the "/512" with ">>9" without any ill effects? At least I > couldn't find anything documented in the code... It's almost certainly a "loff_t", and we should always have generated -EINVAL for negative offsets, so it's pretty much guaranteed to be positive modulo any bugs. Of course, with fatfs, who knows.. Linus