https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
--- Comment #37 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Sandiford from comment #36)
> Created attachment 57602 [details]
> proof-of-concept patch to suppress peeling for gaps
>
> This patch does what I suggested in the previous comment: if the loop needs
> peeling for gaps, try again without that, and pick the better loop. It
> seems to restore the original style of code for SVE.
>
> A more polished version would be a bit smarter about when to retry. E.g.
> it's pointless if the main loop already operates on full vectors (i.e. if
> peeling 1 iteration is natural in any case). Perhaps the condition should
> be that either (a) the number of epilogue iterations is known to be equal to
> the VF of the main loop or (b) the target is known to support partial
> vectors for the loop's vector_mode.
>
> Any thoughts?
Even more iteration looks bad. I do wonder why when gather can avoid
peeling for GAPs using load-lanes cannot? Also for the stores we
seem to use elementwise stores rather than store-lanes.
To me the most obvious thing to try optimizing in this testcase is DR
analysis. With -march=armv8.3-a I still see
t.c:26:22: note: === vect_analyze_data_ref_accesses ===
t.c:26:22: note: Detected single element interleaving array1[0][_8] step 4
t.c:26:22: note: Detected single element interleaving array1[1][_8] step 4
t.c:26:22: note: Detected single element interleaving array1[2][_8] step 4
t.c:26:22: note: Detected single element interleaving array1[3][_8] step 4
t.c:26:22: note: Detected single element interleaving array1[0][_1] step 4
t.c:26:22: note: Detected single element interleaving array1[1][_1] step 4
t.c:26:22: note: Detected single element interleaving array1[2][_1] step 4
t.c:26:22: note: Detected single element interleaving array1[3][_1] step 4
t.c:26:22: missed: not consecutive access array2[_4][_8] = _69;
t.c:26:22: note: using strided accesses
t.c:26:22: missed: not consecutive access array2[_4][_1] = _67;
t.c:26:22: note: using strided accesses
so we don't figure
Creating dr for array1[0][_1]
base_address: &array1
offset from base address: (ssizetype) ((sizetype) (m_111 * 2) * 2)
constant offset from base address: 0
step: 4
base alignment: 16
base misalignment: 0
offset alignment: 4
step alignment: 4
base_object: array1
Access function 0: {m_111 * 2, +, 2}<nw>_4
Access function 1: 0
Creating dr for array1[0][_8]
analyze_innermost: success.
base_address: &array1
offset from base address: (ssizetype) ((sizetype) (m_111 * 2 + 1) * 2)
constant offset from base address: 0
step: 4
base alignment: 16
base misalignment: 0
offset alignment: 2
step alignment: 4
base_object: array1
Access function 0: {m_111 * 2 + 1, +, 2}<nw>_4
Access function 1: 0
belong to the same group (but the access functions tell us it worked out).
Above we fail to split the + 1 to the constant offset.
See my hint to use int32_t m instead of uint32_t yielding
t.c:26:22: note: Detected interleaving load of size 2
t.c:26:22: note: _2 = array1[0][_1];
t.c:26:22: note: _9 = array1[0][_8];
t.c:26:22: note: Detected interleaving load of size 2
t.c:26:22: note: _18 = array1[1][_1];
t.c:26:22: note: _23 = array1[1][_8];
t.c:26:22: note: Detected interleaving load of size 2
t.c:26:22: note: _32 = array1[2][_1];
t.c:26:22: note: _37 = array1[2][_8];
t.c:26:22: note: Detected interleaving load of size 2
t.c:26:22: note: _46 = array1[3][_1];
t.c:26:22: note: _51 = array1[3][_8];
t.c:26:22: note: Detected interleaving store of size 2
t.c:26:22: note: array2[_4][_1] = _67;
t.c:26:22: note: array2[_4][_8] = _69;
(and SLP being thrown away because we can use load/store lanes)
