Serious code size regression from 3.0.2 to now part two

tm tm@mail.kloo.net
Sat Jul 27 05:54:00 GMT 2002


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:
> > 
> >  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.
> 
> It appears the code is geared towards the r0 < 0 case.  Assuming both
> r1 and r0 need to contain the result, optimized code would be:
...

It looks like both GCC-3.0.4 and CVS initially generate similar RTL
and GCC-3.0.4 manages to clean up the code, while GCC CVS does not.

I managed to track the insn which generates the equivalent of "bra .L323"
in the previous code through GCC-3.0.4:

[tm@localhost test]$ grep "jump_insn 7693" *
map_fog.i.00.rtl:(jump_insn 7693 7692 7694 (set (pc)
map_fog.i.01.sibling:(jump_insn 7693 7691 7694 (set (pc)
map_fog.i.03.jump:(jump_insn 7693 7691 7694 (set (pc)
map_fog.i.04.cse:(jump_insn 7693 7691 7694 (set (pc)
map_fog.i.05.addressof:(jump_insn 7693 7691 7694 (set (pc)
map_fog.i.09.gcse:(jump_insn 7693 7691 7694 (set (pc)
map_fog.i.10.loop:(jump_insn 7693 7691 7694 (set (pc)
map_fog.i.11.cse2:(jump_insn 7693 7691 7694 (set (pc)
map_fog.i.12.cfg:(jump_insn 7693 7691 7694 (set (pc)
map_fog.i.14.life:(jump_insn 7693 7691 7694 (set (pc)
map_fog.i.15.combine:(jump_insn 7693 7691 7694 (set (pc)
map_fog.i.16.ce:(jump_insn 7693 7691 7694 (set (pc)
map_fog.i.17.regmove:(jump_insn 7693 7691 7694 (set (pc)
map_fog.i.19.lreg:(jump_insn 7693 7691 7694 (set (pc)
map_fog.i.20.greg:(jump_insn 7693 7691 7694 (set (pc)
map_fog.i.21.postreload:(jump_insn 7693 7691 7694 (set (pc)
[tm@localhost test]$ 

So it looks like flow2 was removing the jump instruction in 3.0.4
but is no longer optimizing out the jump in CVS.

Toshi




More information about the Gcc-bugs mailing list