https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #65 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
We can see ~2% code size regression on average with CSiBE.
There are some cases which register elimination doesn't
work well. An example is
int foo (int x)
{
int y[100];
bar (&y[4], x);
return y[4];
}
which is compiled to a lengthy code:
foo:
sts.l pr,@-r15
mov.w .L6,r1
mov r4,r5
mov.w .L3,r2
sub r1,r15
mov.l .L4,r0
mov r15,r3
mov.w .L5,r1
add #4,r3
add r3,r2
add r2,r1
mov.l r1,@r15
mov r1,r4
jsr @r0
add #16,r4
mov.l @r15,r1
mov.l @(16,r1),r0
mov.w .L6,r7
add r7,r15
lds.l @r15+,pr
rts
nop
.align 1
.L6:
.short 404
.L3:
.short 400
.L5:
.short -400
with -O2. It seems that SH's very limited addsi3 insn doesn't
match with the LRA's register elimination. The canonical insn
like (set reg_a (plus reg_b const_int)) are scaned at register
elimination phase.
On SH, it's expanded to the 2 insns (set reg_a const_int) and
(set reg_a (plus reg_a reg_b)) when const_int doesn't fit in 8-bit.
This makes the elimination process unhappy.
