From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15207 invoked by alias); 10 Dec 2001 19:29: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 15183 invoked from network); 10 Dec 2001 19:29:02 -0000 Received: from unknown (HELO gra-vd1.iram.es) (150.214.224.250) by sources.redhat.com with SMTP; 10 Dec 2001 19:29:02 -0000 Received: from iram.es (localhost [127.0.0.1]) by gra-vd1.iram.es (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id fBAJRjS17043; Mon, 10 Dec 2001 20:27:50 +0100 Message-ID: <3C150CB1.3080502@iram.es> Date: Mon, 10 Dec 2001 11:31:00 -0000 From: Gabriel Paubert User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.5) Gecko/20011016 X-Accept-Language: en-us MIME-Version: 1.0 To: Franz Sirl , gcc@gcc.gnu.org Subject: Re: Optimizations on long long multiply/divide on PowerPC32 don't work References: <200112101938.4189@enzo.bigblue.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-12/txt/msg00522.txt.bz2 Franz Sirl wrote: > 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; I believe inode->i_blksize is always a multiple of 512. So the least significant 9 bits are guaranteed to be zero and you can safely replace the divide by a shift. > It calculates the number of blocks here, so the rounding up might be wanted... There is already a round-up to the next multiple of inode->i_blksize by the addition and masking. > Hehe, yeah, exactly :-). Anyway, Richard's patch works fine and gcc3 now is > able to optimize the divdi3 call away. Great, does it also work for unsigned (more interesting for me). Gabriel.