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.
