powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?

[Sergei Poselenov]

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&timestamp=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&timestamp=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&timestamp_a=2003-01-01%2012:00:00&timestamp_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.
>