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

[Andrzej Warzyński]

================
@@ -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.
----------------
banach-space wrote:

This update is unclear to me and might be modifying the semantics of `vector.gather` + `vector.scatter` that's inconsistent with how these ops and their operands are interpreted in various places. Lets pause for a moment to discuss.

To me, the strides in examples like the one below should/are encoded in the memref rather than input `index_vec`:
```mlir
vector.gather %base[%c0][%v], %mask, %pass_thru : memref<4xf32, strided<[2]>>
```

The updated comment implies the opposite - that the strides should be encoded both within the memref **and** the index vector.  So, effectively, we would be encoding the same information in two places. To me that's confusing and not how I have been reasoning about these ops.

Why do we need this updated assumption?

Also, I don't want to sound like nit-picking, but `tensor.extract` is not a particularly good example - it only extracts **one** element. `tensor.extract_slice` might be better.

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