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.
