From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9605 invoked by alias); 17 Jan 2008 14:48:47 -0000 Received: (qmail 9593 invoked by uid 22791); 17 Jan 2008 14:48:45 -0000 X-Spam-Check-By: sourceware.org Received: from ocean.emcraft.com (HELO ocean.emcraft.com) (213.221.7.182) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 Jan 2008 14:48:17 +0000 Received: from [172.17.0.10] (helo=[172.17.0.10]) by ocean.emcraft.com with esmtp (Exim 4.43) id 1JFW2G-0000Lm-FX; Thu, 17 Jan 2008 17:48:06 +0300 Message-ID: <478F6AAA.4090402@emcraft.com> Date: Thu, 17 Jan 2008 14:52:00 -0000 From: Sergei Poselenov User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: Andrew Haley CC: gcc@gcc.gnu.org, 'rt' Subject: Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression? [Emcraft #11717] References: <478DE61D.3060709@emcraft.com> <18317.63987.952041.910752@zebedee.pink> <478E0CC7.6060107@emcraft.com> <18318.13924.827172.239806@zebedee.pink> <478E3A4F.7070700@emcraft.com> <18318.15219.833552.235@zebedee.pink> In-Reply-To: <18318.15219.833552.235@zebedee.pink> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -104.2 (---------------------------------------------------) X-Spam-Report: Spam detection software, running on the system "ocean.emcraft.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hello Andrew, Andrew Haley wrote: > Sergei Poselenov writes: > > Hello Andrew, > > > > > Now, I sympathize that in your particular case you have a code size > > > regression. This happens: when we do optimization in gcc, some code > > > bases will lose out. All that we can promise is that we try not to > > > make it worse for most users. > > > > > > What we can do is compare your code that has got much worse, and try > > > to figure out why. > > > > > > > Would the generated asm listings be enough? Or should I send > > the preprocessed sources as well? > > Both. > > Rather than sending stuff, best to stick it on a web site if you can. > [...] Content analysis details: (-104.2 points, 2.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -100 USER_IN_WHITELIST From: address is in the user's white-list -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00266.txt.bz2 Hello Andrew, Andrew Haley wrote: > Sergei Poselenov writes: > > Hello Andrew, > > > > > Now, I sympathize that in your particular case you have a code size > > > regression. This happens: when we do optimization in gcc, some code > > > bases will lose out. All that we can promise is that we try not to > > > make it worse for most users. > > > > > > What we can do is compare your code that has got much worse, and try > > > to figure out why. > > > > > > > Would the generated asm listings be enough? Or should I send > > the preprocessed sources as well? > > Both. > > Rather than sending stuff, best to stick it on a web site if you can. > Here it is: Preprocessed and assembler code generated by the GCC 4.2.2 ppc-linux cross-compiler: http://www.emcraft.com/codesize/gcc-4.2.2/interrupts.i http://www.emcraft.com/codesize/gcc-4.2.2/interrupts.s The same code built with gcc-4.0.0 cross-compiler: http://www.emcraft.com/codesize/gcc-4.0.0/interrupts.i http://www.emcraft.com/codesize/gcc-4.0.0/interrupts.s Again, for convenience, the compilation string is: ppc-linux-gcc -g -Os -fPIC -D__KERNEL__ -DTEXT_BASE=0xfffc0000 -I/work/psl/tmp/u-boot/include -fno-builtin -nostdinc -isystem /opt/eldk-4.2-01-08/usr/bin/../lib/gcc/powerpc-linux/4.2.2/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -msoft-float -Wa,-m440 -mcpu=440 -DCONFIG_440=1 -Wall -Wstrict-prototypes -c interrupts.c The 'size' output for both the cases: text data bss dec hex filename 2696 60 1536 4292 10c4 interrupts.o and text data bss dec hex filename 2424 88 1536 4048 fd0 interrupts.o > Having said that, your example is tiny, so it's likely that it won't > be very representative, and the less representative the code is the > less likely a gcc maintainer will be interested. But at least we'll > be able to see the difference. > I agree. Actually, the CSiBE results are impressive: I've built the bzip2 library for powerpc and got similar results. I wonder why GCC maintainers are ignoring the -Os regression for most of their cases (at least for powerpc). Thanks, Sergei > Andrew. >