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 18:18:13 -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:
> >
> > 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