From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7204 invoked by alias); 16 Jan 2008 13:56:01 -0000 Received: (qmail 7191 invoked by uid 22791); 16 Jan 2008 13:56:00 -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; Wed, 16 Jan 2008 13:55:29 +0000 Received: from [172.17.0.10] (helo=[172.17.0.10]) by ocean.emcraft.com with esmtp (Exim 4.43) id 1JF8gr-0002b6-2M; Wed, 16 Jan 2008 16:52:30 +0300 Message-ID: <478E0CC7.6060107@emcraft.com> Date: Wed, 16 Jan 2008 15:59: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 Subject: Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression? References: <478DE61D.3060709@emcraft.com> <18317.63987.952041.910752@zebedee.pink> In-Reply-To: <18317.63987.952041.910752@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, I've just noted an error in my calculations: not 40%, but 10% regression (used gdb to do the calculations and forgot to convert inputs to float). Sorry. But the problem still persists for me - I'm building an embedded firmware (U-Boot) and it doesn't fit into the reserved space anymore. [...] 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/msg00237.txt.bz2 Hello, I've just noted an error in my calculations: not 40%, but 10% regression (used gdb to do the calculations and forgot to convert inputs to float). Sorry. But the problem still persists for me - I'm building an embedded firmware (U-Boot) and it doesn't fit into the reserved space anymore. Andrew Haley wrote: > Sergei Poselenov writes: > > Hello all, > > > > I'm using the ppc-linux gcc-4.2.2 compiler and noted the code > > size have increased significantly (about 40%!), comparing with > > old 4.0.0 when using the -Os option. Same code, same compile- > > and configuration-time options. Binutils are differ > > (2.16.1 vs 2.17.50), though. > > > > I've looked at the CSiBE testing results for ppc-elf with -Os, > > comparing gcc_4_0_0 with mainline and found that the mainline > > actually optimizes better, at least for the CSiBE test environment. > > After some analysis I've came to the following results: > > Number of packages in the CSiBE test environment: 863 > > N of packages where mainline GCC optimizes better: 290 > > N of packages where mainline GCC optimizes worse: 436 > > > > And the regression in code size is up to 40%, like in my case. > > 40% seems severe, but it may be an outlier. What is the average > increase in code size, including the packages where it got better? > Specifically, in my case the digits are as follows (as reported by 'size'): gcc 4.2.2: text data bss dec hex filename 2696 60 1536 4292 10c4 interrupts.o gcc 4.0.0: text data bss dec hex filename 2424 88 1536 4048 fd0 interrupts.o (about 10% regression) As for the CSiBE results - the average regression is 3%, including top 3 winners: 100% (32768 vs 16384 for "linux-2.4.23-pre3-testplatform - arch/testplatform/kernel/init_task") 35% (1440 vs 1064 for "teem-1.6.0-src - src/air/enum") 34% (1712 vs 1280 for "teem-1.6.0-src - src/nrrd/encodingHex") (See http://www.inf.u-szeged.hu/csibe/osingle.php?branchid=mainline&targetid=ppc-elf×tamp=2008-01-15%2012:00:00&flags=-Os&csibever=2.x.x&projectid=---%20all%20files%20---&finish_button=Finish for mainline results, and http://www.inf.u-szeged.hu/csibe/osingle.php?branchid=gcc_4_0_0_release&targetid=ppc-elf×tamp=2003-01-01%2012:00:00&flags=-Os&csibever=2.x.x&projectid=---%20all%20files%20---&finish_button=Finish for gcc_4_0_0_release results) For comparison bar chart see http://www.inf.u-szeged.hu/csibe/ocomp.php?branchid_a=gcc_4_0_0_release&branchid_b=mainline&targetid_a=ppc-elf&targetid_b=ppc-elf×tamp_a=2003-01-01%2012:00:00×tamp_b=2008-01-15%2012:00:00&flags_a=-Os&flags_b=-Os&csibever_a=2.x.x&csibever_b=2.x.x&dataview=Code%20size&viewmode=Bar%20chart&finish_button=Finish > > What I'm missing here? Apparently, just "-Os" is not enough to > > get the best size-optimized code? > > Not necessarily. -Os is mostly [*] the same as -O2 but with > optimizations that might reasonably be expected to cause code size > increase disabled. You might find some better combination of options > for your code base. > Understood. I raised the question in a hope that somebody already have a set of useful options for powerpc cross to try with -Os. Thanks, Sergei > Andrew. > > [*] Full disclosure: There are a few optimizations, such as code > hoisting, that are specially used with -Os. There are also some > passes with special tuning for -Os. >