[Bug target/54065] New: [SH] Prefer @(R0,Rn) addressing for floating-point load/store

[Bug target/54065] New: [SH] Prefer @(R0,Rn) addressing for floating-point load/store

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54065

             Bug #: 54065
           Summary: [SH] Prefer @(R0,Rn) addressing for floating-point
                    load/store
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: olegendo@gcc.gnu.org
            Target: sh*-*-*


The following function

float test00 (float* x)
{
  return x[10] + x[1] + x[20] + x[30];
}

compiled with e.g. '-O2 -m4-single -ml' results in:

        mov     r4,r2
        mov     r4,r1
        add     #40,r2
        add     #4,r1
        fmov.s  @r2,fr0
        fmov.s  @r1,fr1
        add     #76,r1
        add     #120,r4
        fadd    fr1,fr0
        fmov.s  @r1,fr1
        fadd    fr1,fr0
        fmov.s  @r4,fr1
        rts
        fadd    fr1,fr0

which would be better as:

    mov    #40,r0
    fmov.s    @(r0,r2),fr0
    mov    #4,r0
    fmov.s    @(r0,r1),fr1
    mov    #80,r0
    fadd    fr1,fr0
    fmov.s    @(r0,r1),fr1
    mov    #120,r0    
    fadd    fr1,fr0
    fmov.s    @(r0,r4),fr1
    rts
    fadd    fr1,fr0

In sh.md (around line 11724) there are some old peephole patterns that were
supposed to handle this case, I guess.  However, they seem to be defunct.

[Bug target/54065] [SH] Prefer @(R0,Rn) addressing for floating-point load/store

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54065

--- Comment #1 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-08-23 23:09:07 UTC ---
On rev 190580 I've tried out replacing the sh_legitimize_address function with
the following one:



sh_legitimize_address (rtx x, rtx oldx, enum machine_mode mode)
{
  if (flag_pic)
    x = legitimize_pic_address (oldx, mode, NULL_RTX);

  if (TARGET_SHMEDIA)
    return x;

  if (GET_CODE (x) == PLUS && CONST_INT_P (XEXP (x, 1))
      && BASE_REGISTER_RTX_P (XEXP (x, 0)))
    {
      /* SH2A has displacement floating-point loads and stores.
     On everything else change the address to use index addressing.  */
      if (FLOAT_MODE_P (mode) && TARGET_FPU_ANY && ! TARGET_SH2A)
    {
      rtx reg = gen_reg_rtx (Pmode);
      emit_insn (gen_move_insn (reg, XEXP (x, 1)));
      return gen_rtx_PLUS (Pmode, reg, XEXP (x, 0));
    }

      struct disp_adjust adj = sh_find_mov_disp_adjust (mode,
                            INTVAL (XEXP (x, 1)));

      if (adj.offset_adjust != NULL_RTX && adj.mov_disp != NULL_RTX)
    {
      rtx sum = expand_binop (Pmode, add_optab, XEXP (x, 0),
                  adj.offset_adjust, NULL_RTX, 0,
                  OPTAB_LIB_WIDEN);
      return gen_rtx_PLUS (Pmode, sum, adj.mov_disp);
    }
    }

  return x;
}

This 'fixes' the issue mentioned in the description.  Looking at CSiBE
result-size there is a small overall improvement, but there are also quite some
code size increases.  It seems difficult to select the optimal addressing mode
for these kind of situations without looking at the surrounding code.
It also seems that transforming every displacement address into an index
address  will make it difficult for the auto-inc-dec pass to find
opportunities, as it is not smart enough to undo the indexed address
transformation.  Last but not least, the indexed address increases pressure on
R0 of course.