Serious code size regression from 3.0.2 to now part two

tm tm@mail.kloo.net
Thu Jul 25 19:34:00 GMT 2002


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:

 5124                   .L320:
 5125 2a02 4011                 cmp/pz  r0
 5126 2a04 8F0C                 bf/s    .L322
 5127 2a06 6813                 mov     r1,r8
 5128 2a08 9226                 mov.w   .L683,r2
 5129 2a0a 3027                 cmp/gt  r2,r0
 5130 2a0c 8F09                 bf/s    .L323
 5131 2a0e 6103                 mov     r0,r1
 5132 2a10 A007                 bra     .L323
 5133 2a12 6123                 mov     r2,r1
 5134 2a14 00090009             .align 5
 5134      00090009
 5134      00090009
 5135                   .L322:
 5136 2a20 E100                 mov     #0,r1
 5137                   .L323:
 5138 2a22 6013                 mov     r1,r0
 5139 2a24 4818                 shll8   r8
..

This is really twisted branch logic.

The gist of this problem is that gcc is no longer generating simple
branches of the form:

	cmp	
	bt
	foo
		/* fall through */
Lx:
	bar

For some reason, it is now generating branches of the form:

	cmp	blah
	bf/s	L1
	(stuff here)
	bra	L2
	.align	5
L1:
	blah
L2:
	blah

To demonstrate the magnitude of this problem, here's a quick
demonstration:

[tm@localhost temp]$ grep "align 5" *old* | wc -l
     16

[tm@localhost temp]$ grep "align 5" *new* | wc -l
     97

There's a 6x increase in the number of 32-byte alignment
directives even with basic block reordering disabled!

Toshi



More information about the Gcc-bugs mailing list