On Wed, Jul 29, 2026 at 10:53 AM Andrew Stubbs <[email protected]> wrote:
>
> On 29/07/2026 09:36, Robin Dapp wrote:
> >> Also, since scatter operations use fixed strides the question of
> >> in-order, or not, is actually a non-issue even on GCN so we could set
> >> the flag safely.
> >
> > Consider stride 0 and stride < element size, though. I'm currently
> > thinking of how/where to add the proper versioning decision for that.
>
> I'm generally of the opinion that the compiler should not compromise the
> speed of well written code to cover whatever abomination somehow manages
> to convince the autovectorizer to generate zero stride lengths.
>
> My interest is in OpenMP/OpenACC where the multithreading already
> destroyed all notion of left-to-rightness that the vectorizer tries so
> hard to preserve. In these cases, the end-user has declared and promised
> that the loop iterations are independent, and if it turns out that's not
> the case, then that's on them.
>
> However, if riscv has the instructions and hardware to handle that case,
> would it not naturally fall to the "scatter_store" expander to handle
> these cases? This feeling like a back-end decision, to me.
>
> Or, are you thinking of versioning it in gimple, somehow? I assume this
> would require knowing how the backend instruction handles the writes...
> would the plan be to never ask the backend to do something in-order if
> it can't promise that?
It's when the vectorizer vectorizes a store with an invaraint but not
known non-zero stride or when there a scatter pattern
for (int i ...)
a[b[i]] = ...;
where we cannot obviously "prove" there's no dependence between
a[b[0]] and a[b[1]] that we can either not vectorize or have a left-to-right
scatter operation. For strided stores we can version on the invariant
stride being non-zero (or again rely on left-to-right, which riscv supports)
Sure if the user writes a #pragma ivdep or similar openacc/openmp
annotation we do not have to do dependence checking and are free
to use unordered variants.
Richard.
>
> Andrew
