[Mlir-commits] [mlir] [mlir][xegpu] Remove chunk_size attribute; infer from types (PR #205122)

[Artem Kroviakov]

================
@@ -857,17 +856,19 @@ def XeGPU_StoreScatterOp : XeGPU_Op<"store", [MemoryEffects<[MemWrite]>, AnchorL
         1D memref or pointer (ui64, ui32, i64 or i32).
 
     - `offsets`: represents offsets from dest.
-        offsets is a vector of `index` type and vector length is either the subgroup size
-        or 1 at lane level. scalar offset is also valid for lane level.
+        offsets is a vector of `index` type with the same shape as the value.
+        A scalar offset is also valid: one lane then writes only one element.
 
     - `mask`: is a vector of `i1` type, which is used to mask out the memory access.
-        mask is a vector of size equal to the subgroup size, or 1 at lane level.
-        scalar mask is also valid for lane level.
-
-    - `chunk_size`: [optional] represents contiguous number of elements to store to per work item.
+        mask has the same shape as the offsets and the value. Each element applies
+        to one lane. A scalar mask is also valid, and gates that one element.
 
     - `l1_hint`, `l2_hint`, `l3_hint`: [optional] cache hints for each level of cache.
 
+    - `contiguity`: [optional] the number of neighbouring elements each lane may
----------------
akroviakov wrote:

So contiguity tells the block size so that we know how many contiguous blocks a lane loads in a strided fashion to fill its sub-tile of sg_data? E.g., a 1x16 can be filled as 4 vector<4> loads, or 2 vector<8> or, 1 vector<16>.

The propagation limits inst_data to lane_layout*lane_data (lane_data is uarch limited) such that the above number of vectors becomes an unrolling factor, which is unknown unless a user supplies his own lane_data.
Is my understanding correct?

If a user wants that level of customization and the attribute is distribution-local (takes no part in the xevm lowering), is it not the user's responsibility to customize the distribution itself via a custom anchor layouts? Why do we need a new op-native attribute that will be temporary in the dist. pipeline, only to support part of another temporary attribute (layout)?

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