[Mlir-commits] [mlir] [mlir] Implement indexed access op interfaces for memref, vector, gpu, nvgpu (PR #177014)

[Krzysztof Drewniak]

================
@@ -2103,6 +2111,14 @@ def Vector_GatherOp :
     memory at an address aligned to this boundary. Violating this requirement
     triggers immediate undefined behavior.
 
+    Note that if the base argument is not contiguous in memory (for example,
+    it is the result of a `tensor.extract` or a `memref.subview`), the entries
+    of `index_vec` must respect the strieds in the underlying memory and are
+    applied as pure 1-D offsets and are not decomposed in order to apply
+    the strides on the base.
----------------
krzysz00 wrote:

Last I checked, vector.gather and vector.scatter make _no_ provision for the strides of the memref - at least, that's how I always saw these operations and their lowerings.

That is, in `vector.gather %base[%x][%v], %mask, %pass_thru : memref<4xf32, strided<[2]>>`, the [2] applies to that `%x` (the memref part) and the `%v` is always a strict linear 1-D offset - so if you want to gather what would be elements 0, 1, 2 of that strided-by-2 memref, you need `%v = <0, 2, 4>`

Otherwise, the lowering of vector.gather to LLVM (see https://github.com/llvm/llvm-project/blob/0c07203e075bf6a9d796087b6a5b673789eeb570/mlir/lib/Conversion/VectorToLLVM/ConvertVectorToLLVM.cpp#L135 and https://github.com/llvm/llvm-project/blob/0c07203e075bf6a9d796087b6a5b673789eeb570/mlir/lib/Conversion/VectorToLLVM/ConvertVectorToLLVM.cpp#L314 ) would actually be accounting for the strides on the memref. You will note that it does not do this.

This isn't _changing_ the operation's semantics, but documenting what they currently are.

I've added this clarification so that it's obvious why we're allowed to fold a subview into a vector.gather rather unconditionally.

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