From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28431 invoked by alias); 10 Dec 2001 18:49:50 -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 28338 invoked from network); 10 Dec 2001 18:49:29 -0000 Received: from unknown (HELO linuxpc1.lauterbach.com) (194.195.165.177) by sources.redhat.com with SMTP; 10 Dec 2001 18:49:29 -0000 Received: (qmail 19116 invoked by uid 82); 10 Dec 2001 18:49:11 -0000 Received: from Franz.Sirl-kernel@lauterbach.com by linuxpc1.lauterbach.com with qmail-scanner-1.01 (inocmd32: /. . Clean. Processed in 3.460124 secs); 10 Dec 2001 18:49:11 -0000 Received: from dialin-212-144-150-134.arcor-ip.net (HELO there) (212.144.150.134) by linuxpc1.lauterbach.com with SMTP; 10 Dec 2001 18:49:08 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Franz Sirl Message-Id: <200112101938.4189@enzo.bigblue.local> To: Linus Torvalds Subject: Re: Optimizations on long long multiply/divide on PowerPC32 don't work Date: Mon, 10 Dec 2001 10:59:00 -0000 X-Mailer: KMail [version 1.3.2] Cc: Richard Henderson , References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SW-Source: 2001-12/txt/msg00513.txt.bz2 On Monday 10 December 2001 18:08, Linus Torvalds wrote: > 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? It's this code fragment: inode->i_blocks = ((inode->i_size + inode->i_blksize - 1) & ~(inode->i_blksize - 1)) / 512; that is in inode.c/fat_read_root() and fat_fill_inode(). It's inode->i_size that is of type loff_t here. > 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. It calculates the number of blocks here, so the rounding up might be wanted... > > 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.. Hehe, yeah, exactly :-). Anyway, Richard's patch works fine and gcc3 now is able to optimize the divdi3 call away. Franz.