[Bug tree-optimization/65447] New: AArch64: iv-opt causes bad addressing

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65447

            Bug ID: 65447
           Summary: AArch64: iv-opt causes bad addressing
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: amker at gcc dot gnu.org

Hi,
For below case extracted from spec2006 (and even worse in real case), loops
containing a significant number of memory accesses generate very inefficient
code.  This is due to iv-opt hitting a limit and choosing the wrong induction
variable, resulting in addressing modes with huge offsets and all loads/stores
expanded into 2 or 3 instructions.

The source code is like:
void foo (double *p)
{
  int i;
  for (i = -20000; i < 200000; i+= 40)
    {
      p[i+0] = 1.0;
      p[i+1] = 1.0;
      p[i+2] = 1.0;
      p[i+3] = 1.0;
      p[i+4] = 1.0;
      p[i+5] = 1.0;
      p[i+6] = 1.0;
      p[i+7] = 1.0;
      p[i+8] = 1.0;
      p[i+9] = 1.0;
      p[i+10] = 1.0;
      p[i+11] = 1.0;
      p[i+12] = 1.0;
      p[i+13] = 1.0;
      p[i+14] = 1.0;
      p[i+15] = 1.0;
      p[i+16] = 1.0;
      p[i+17] = 1.0;
      p[i+18] = 1.0;
      p[i+19] = 1.0;
      p[i+20] = 1.0;
      p[i+21] = 1.0;
      p[i+22] = 1.0;
      p[i+23] = 1.0;
      p[i+24] = 1.0;
      p[i+25] = 1.0;
      p[i+26] = 1.0;
      p[i+27] = 1.0;
      p[i+28] = 1.0;
      p[i+29] = 1.0;
      p[i+30] = 1.0;
      p[i+31] = 1.0;
      p[i+32] = 1.0;
      p[i+33] = 1.0;
      p[i+34] = 1.0;
      p[i+35] = 1.0;
      p[i+36] = 1.0;
      p[i+37] = 1.0;
      p[i+38] = 1.0;
      p[i+39] = 1.0;
    }
}

And comparison of generated assembly and the optimal one:
*** test.S    2015-03-17 17:04:41.677033862 +0800
--- ../../../trunk-orig/target/bin/test.S    2015-03-17 17:03:45.377033869
+0800
***************
*** 7,40 ****
      .type    foo, %function
  foo:
      fmov    d0, 1.0e+0
!     sub    x1, x0, #159744
!     add    x2, x0, 1597440
!     sub    x0, x1, #256
!     add    x1, x2, 2560
      .p2align 2
  .L2:
!     stp    d0, d0, [x0]
!     stp    d0, d0, [x0, 16]
!     stp    d0, d0, [x0, 32]
!     stp    d0, d0, [x0, 48]
!     stp    d0, d0, [x0, 64]
!     stp    d0, d0, [x0, 80]
!     stp    d0, d0, [x0, 96]
!     stp    d0, d0, [x0, 112]
!     stp    d0, d0, [x0, 128]
!     stp    d0, d0, [x0, 144]
!     stp    d0, d0, [x0, 160]
!     stp    d0, d0, [x0, 176]
!     stp    d0, d0, [x0, 192]
!     stp    d0, d0, [x0, 208]
!     stp    d0, d0, [x0, 224]
!     stp    d0, d0, [x0, 240]
!     add    x0, x0, 320
!     cmp    x1, x0
!     stp    d0, d0, [x0, -64]
!     stp    d0, d0, [x0, -48]
!     stp    d0, d0, [x0, -32]
!     stp    d0, d0, [x0, -16]
      bne    .L2
      ret
      .size    foo, .-foo
--- 7,53 ----
      .type    foo, %function
  foo:
      fmov    d0, 1.0e+0
!     mov    x8, 56064
!     movk    x8, 0x1a, lsl 16
!     mov    x3, 0
      .p2align 2
  .L2:
!     add    x2, x0, x3
!     add    x3, x3, 320
!     sub    x1, x2, #159744
!     sub    x2, x2, #155648
!     sub    x4, x2, #4088
!     sub    x7, x2, #4080
!     stp    d0, d0, [x1, -256]
!     sub    x6, x2, #4072
!     sub    x5, x2, #4064
!     stp    d0, d0, [x1, -240]
!     cmp    x3, x8
!     stp    d0, d0, [x1, -224]
!     stp    d0, d0, [x1, -208]
!     stp    d0, d0, [x1, -192]
!     stp    d0, d0, [x1, -176]
!     stp    d0, d0, [x1, -160]
!     stp    d0, d0, [x1, -144]
!     stp    d0, d0, [x1, -128]
!     stp    d0, d0, [x1, -112]
!     stp    d0, d0, [x1, -96]
!     stp    d0, d0, [x1, -80]
!     stp    d0, d0, [x1, -64]
!     stp    d0, d0, [x1, -48]
!     stp    d0, d0, [x1, -32]
!     stp    d0, d0, [x1, -16]
!     str    d0, [x1]
!     sub    x1, x2, #4048
!     str    d0, [x4]
!     sub    x4, x2, #4056
!     sub    x2, x2, #4040
!     str    d0, [x7]
!     str    d0, [x6]
!     str    d0, [x5]
!     str    d0, [x4]
!     str    d0, [x1]
!     str    d0, [x2]
      bne    .L2
      ret
      .size    foo, .-foo


Actually in this case most IVs differ to each other by a constant offset of
base address, they point to same memory object and have same step. These
address type IVs should be categorize into a single group as if it's ONE IV
use. As a result, the number of IV uses can be decreased thus we can run
expensive IV algorithm to make better choice.

I can see this only hits architectures like arm/aarch64, because it has more
addressing modes than simple register direct one, also it doesn't support
arbitrary constant offset in memory reference.  But, anyway, this should be
handled as target independent issue.

I am working on this.