[Bug tree-optimization/99873] New: [11 Regression] GCC no longer makes as much use of ST3

["rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 99873
           Summary: [11 Regression] GCC no longer makes as much use of ST3
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rsandifo at gcc dot gnu.org
                CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
            Target: aarch64*-*-*

For:

void
f (int *restrict x, int *restrict y, int *restrict z, int n)
{
  for (int i = 0; i < n; i += 3)
    {
      x[i] = y[i] + z[i];
      x[i + 1] = y[i + 1] - z[i + 1];
      x[i + 2] = y[i + 2] | z[i + 2];
    }
}

GCC 10 produced a nice loop using LD3 and ST3:

.L4:
        ld3     {v4.4s - v6.4s}, [x4], 48
        ld3     {v16.4s - v18.4s}, [x6], 48
        add     v1.4s, v16.4s, v4.4s
        sub     v2.4s, v5.4s, v17.4s
        orr     v3.16b, v18.16b, v6.16b
        st3     {v1.4s - v3.4s}, [x5], 48
        cmp     x8, x4
        bne     .L4

But GCC 11 instead uses lane stores:

.L4:
        ld3     {v4.4s - v6.4s}, [x9], 48
        mov     x8, x4
        ld3     {v16.4s - v18.4s}, [x11], 48
        add     x16, x4, 24
        add     x15, x4, 36
        add     x14, x4, 16
        add     x13, x4, 28
        add     x12, x4, 40
        add     v2.4s, v16.4s, v4.4s
        add     x7, x4, 20
        sub     v1.4s, v5.4s, v17.4s
        add     x6, x4, 32
        orr     v0.16b, v18.16b, v6.16b
        add     x5, x4, 44
        add     x4, x4, 48
        str     s2, [x8], 12
        st1     {v2.s}[1], [x8]
        st1     {v2.s}[2], [x16]
        st1     {v2.s}[3], [x15]
        str     s1, [x4, -44]
        st1     {v1.s}[1], [x14]
        st1     {v1.s}[2], [x13]
        st1     {v1.s}[3], [x12]
        str     s0, [x4, -40]
        st1     {v0.s}[1], [x7]
        st1     {v0.s}[2], [x6]
        st1     {v0.s}[3], [x5]
        cmp     x10, x9
        bne     .L4

I think this is due to r11-3966 optimistically splitting store groups
in a way that we can't recover from if SLP subsequently fails.

Maybe the easiest thing for GCC 11 would be to block the split if the
target supports IFN_STORE_LANES for the group size and element type.
That restores the above case.  Of the two tests affected by r11-3966,
vect-complex-5.c seems better with LD2 & ST4, while the motivating
case (pr97428.c) still uses SLP as intended.