https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126334
Bug ID: 126334
Summary: riscv: Scatter uses unordered load variants.
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rdapp at gcc dot gnu.org
Target Milestone: ---
Target: riscv
Our assumption in the vectorizer is that gathers and scatters operate in a
left-to-right manner, i.e. the rightmost element is read/written last. I guess
it's only an issue with stores. Currently, in the riscv code, we use the
unordered flavor of scatter as seen in the simplest of examples:
void g (int * __restrict a, int * __restrict b, int * __restrict c, int n,
long s)
{
for (int i = 0; i < n; i++)
a[b[i]] = c[i];
}
That's wrong if there is an index overlap but won't trigger under qemu. On
real hardware it might. A similar problem happens with strided stores (which
are always unordered) of stride 0. Surely rare and not very useful, but we
still expect that the rightmost elements wins when it currently doesn't.
We can just emit the ordered variants in riscv-v.cc but the fallout is not
clear to me yet. I guess the strided-store case can be worked around in the
vectorizer.
