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?
Andrew
