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

[Md Abdullah Shahneous Bari]

================
@@ -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
----------------
mshahneo wrote:

Not quite "will access" — it is an upper bound, and that is what the vague
"may" was hiding. `xegpu-propagate-layout` resolves it: it turns `contiguity`
into `lane_data`, capped by what one lane can access in one instruction
(`min(getMaxLaneAccessSizeBytes(), contigChunkSize)`). So the final per-lane
width can be smaller than `contiguity`.

Reworded the Arguments entry for both ops to say that, since that is the doc
closest to the attribute:

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