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
- 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, stephen dot clarke at superh dot com,shumpei dot kawasaki at hsa dot hitachi dot com
- Date: Tue, 23 Jul 2002 15:30:05 -0700 (PDT)
- Subject: Re: Serious code size regression from 3.0.2 to now
On Tue, 23 Jul 2002, Joern Rennecke wrote:
> tm wrote:
> > I'm guessing these are helper branches created by split_branches() ?
> >
> > Can we flag helper branches generated by split_branches as unaligned
> > or only aligned on 4 byte boundaries?
>
> No, split_branches doesn't create helper branches for unconditional branches,
> and for conditional branches, it inserts them only in places where there
> is already one conditional branch to that target - inverting the condbranch
> and making it jump around the helper branch.
> And there is already a mechanism in place to suppress excessive alignments
> for unconditional branches that are branched around.
The more I look at this, the worse it seems.
Here's one example:
.L320:
cmp/pz r0
bf/s .L322 <- We jump to L323 by way of L322
mov r1,r8
mov.w .L695,r2
cmp/gt r2,r0
bf/s .L323
mov r0,r1
mov r2,r1
.L323:
mov r1,r0
.L315:
shll8 r8
or r8,r4
mov.l @r14,r8
shll16 r0
or r0,r4
mov.w .L696,r0
mov.l r4,@(60,r10)
mov.l @(r0,r14),r4
add r4,r13
cmp/hs r8,r13
bt .L328
mov.w .L1049,r1; braf r1
mov.l @r12,r1
.L1049:
.word .L916-.L1049
.L328:
mov.w .L697,r7
add r7,r14
mov r14,r15
mov.l @r15+,r14
mov.l @r15+,r13
mov.l @r15+,r12
mov.l @r15+,r11
mov.l @r15+,r10
mov.l @r15+,r9
rts
mov.l @r15+,r8
.align 5
.L322:
bra .L323 <- just a branch - cache-aligned
mov #0,r1
.align 5
It looks like you're right...it's not a helper function to extend the
branch range. It just looks like some weak heuristics somewhere.
Toshi