[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:

I see, so contiguity is the longest memory-contiguous range of elements accessed by a lane in the given offsets pattern, clamped by uArch limitations during the distribution.

The current description lacks an explicit relation of contiguity to the offset pattern, it would make understanding of the upper bound thing quicker (at least to me :) ).

>  Contiguity can be provided by user 

Is the value verified somehow, or does it have precedence above the analysis result on conflicting contiguities?

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