[Mlir-commits] [mlir] [mlir][vector] Make gather/scatter index dimensions separately (PR #194395)

[Andrzej Warzyński]

banach-space wrote:

Thanks for the ping.

There are already a number of unfinished discussions around `vector.gather` / `vector.scatter` semantics. Two recent ones are:

* https://discourse.llvm.org/t/rfc-semantics-of-vector-gather-indices-with-strided-memrefs
* https://github.com/llvm/llvm-project/issues/187215

This PR opens another, broader discussion: it changes not only the lowering, but also the shape of the operation and **the semantic model** by replacing the single index vector with one or more per-dimension index vectors.

I don't think this PR is the right vehicle to settle that. The proposed change is quite involved, and I don't think the community has converged on the semantics yet.

In particular, I think the current one-index-vector abstraction is important to preserve. It maps naturally to important lower-level models:

* LLVM masked gather/scatter:
  https://llvm.org/docs/LangRef.html#masked-vector-gather-and-scatter-intrinsics
* Arm SVE gather loads, e.g. LD1Q gather load:
  https://developer.arm.com/documentation/ddi0602/2026-03/SVE-Instructions/LD1Q--Gather-load-quadwords-?lang=en
* RISC-V RVV indexed loads/stores, e.g. `vluxei*` / `vloxei*` / `vsuxei*` / `vsoxei*`:
  https://docs.riscv.org/reference/isa/unpriv/v-st-ext.html#_vector_indexed_instructions

So while I agree that the current semantics/lowerings need clarification, I don't think we should resolve that by changing the op to model per-dimension indexing.

> resolves the inconsistencies highlighted by https://github.com/llvm/llvm-project/issues/187215

I don't think this change is required to resolve that inconsistency. I have a draft PR to make the existing lowering paths agree, but due to work and personal distractions I haven't been able to polish and upload it yet. I do intend to send
it in the coming weeks.

> it was agreed that these indices would be interpreted in terms of the memref's layout

I don't recall such agreement. The discussion in #187215 shows precisely that this point is still ambiguous: whether the index vector denotes logical offsets in the memref view, or offsets into contiguous underlying storage.

---

Given the limited engagement so far on the semantics of these ops, and the limited upstream usage, I am against making this semantic/API change at this time. I also won't be prioritising this broader discussion right now.

---

I think we should first fix the existing inconsistency, document the current semantics clearly, and wait for more concrete upstream users. This looked promising:

* https://discourse.llvm.org/t/gsoc-vector-sparse-non-unit-stride-dense-vectorization/

but unfortunately it didn't materialise.

Thank you,
-Andrzej

https://github.com/llvm/llvm-project/pull/194395