This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/55212] [SH] Switch to LRA


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]