This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Serious code size regression from 3.0.2 to now
- From: tm <tm at mail dot kloo dot net>
- To: gcc-bugs at gcc dot gnu dot org
- Cc: joern dot rennecke at superh dot com, stephen dot clarke at superh dot com,shumpei dot kawasaki at hsa dot hitachi dot com
- Date: Wed, 17 Jul 2002 18:28:28 -0700 (PDT)
- Subject: Serious code size regression from 3.0.2 to now
version: CVS
host: i386-linux
target: sh-elf
options: -O2 -m4
I'm noticing a huge .text sections size increase in some of my testcases
compared to gcc-3.0.2. Probably the most serious is my testcase map_fog.i
which ballooned from 27580 bytes to 36640 bytes, or by *32.8%* - almost
one-third larger!
I've looked at the output files, and the culprit is this type of code:
.L2212:
bra .L2205
mov r1,r0
.align 5
.L2209:
bra .L2901
cmp/pz r0
.align 5
.L2206:
bra .L2902
cmp/pz r8
.align 5
.L2202:
bra .L2747
mov r1,r0
.align 5
.L2199:
bra .L2903
cmp/pz r0
.align 5
.L2196:
bra .L2904
cmp/pz r8
.align 5
.L2192:
bra .L2185
mov r1,r0
.align 5
.L2189:
bra .L2905
cmp/pz r0
.align 5
.L2186:
bra .L2906
cmp/pz r8
.align 5
.L2182:
mov.w .L3020,r0; braf r0
mov r1,r0
.L3020:
.word .L2740-.L3020
.align 5
.L2179:
mov.w .L3021,r8; braf r8
cmp/pz r0
.L3021:
.word .L2907-.L3021
...
Basically, GCC is now generating HUGE groups of jump instructions which
are aligned to 32-byte boundaries.
Can we possibly avoid aligning single jump instructions on 32-byte
boundaries? This is seriously torpedoing the SH2-4 code density.
Testcase is available on request.
Toshi