This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Serious code size regression from 3.0.2 to now part two
- From: tm <tm at mail dot kloo dot net>
- To: Joern Rennecke <joern dot rennecke at superh dot com>
- Cc: gcc-bugs at gcc dot gnu dot org, shumpei dot kawasaki at hsa dot hitachi dot com,stephen dot clarke at superh dot com
- Date: Fri, 26 Jul 2002 13:24:14 -0700 (PDT)
- Subject: Re: Serious code size regression from 3.0.2 to now part two
On Fri, 26 Jul 2002, Joern Rennecke wrote:
> tm wrote:
> >
> > Okay, I've started using -fno-reorder-blocks on my testcase map_fog.i, and
> > the code size is still about 10% worse than 3.0.x.
> >
> > I think I've tracked this down to really bad branches being generated by
> > gcc. Take a look at this code sequence:
> >
Here's a comparison of code sizes for VideoDraw32OnlyFog32Alpha from
map_fog.i:
gcc3.0.4 gcc-CVS w/-fno-reorder-blocks
0x2702 (8306) 0x2658 (9816)
I counted 78 alignment directives (.align 5) generated by funky branch
logic. If you assume an average of 16 bytes of padding generated per
.align 5 statement, then you wind up with 1248 bytes of padding.
The empirically observed code size difference is 1510 bytes, so
approximately 262 bytes of code size bloat are still unexplained.
Toshi