[Mlir-commits] [mlir] [mlir][XeGPU][Transform] Add gather/scatter coalescing analysis. (PR #201684)

Jianhui Li llvmlistbot at llvm.org
Thu Jun 18 21:47:26 PDT 2026


================
@@ -927,6 +927,49 @@ def XeGPU_MemLayoutAttr : XeGPUAttr<"MemLayout", "mem_layout"> {
 
 }
 
+def XeGPU_CoalesceHintAttr : XeGPUAttr<"CoalesceHint", "coalesce_hint"> {
+  let summary = [{Optional request to coalesce a gather/scatter access.}];
+
+  let description = [{
+    `CoalesceHintAttr` is the optional `coalesce_hint` attribute of
+    `xegpu.load` / `xegpu.store`. It requests that the access group `factor`
+    contiguous elements per lane along the innermost (fastest-changing)
+    dimension of the offsets. `factor` must be a power of two `>= 2`, and the
+    innermost offsets dimension must be a multiple of it.
+
+    The hint has two sources:
+      - it can be set directly by the user (or a higher-level frontend that
+        already knows the access is contiguous-per-lane), in which case the
+        coalesce-gather-scatter analysis is not consulted for that op; or
+      - it is stamped by the analysis when it proves the access coalescible.
+
+    The hint is a *request*, not a commitment: a consumer turns `factor` into
+    a concrete `xegpu.layout` (deriving the `lane_layout` / `lane_data` split
+    from the op's offsets inner extent and the chip's subgroup size) and
+    clears the hint. A consumer that declines (for example, layout propagation
----------------
Jianhui-Li wrote:

I view attribute is just a field that describes the OP's property, instead of a "request to a specific optimization". An optimization pass may or may not use it, but should not remove it.   Others optimization might find it useful even one doesn't. 

So Instead of describing it as a request tied to "coalesce" optimization, how about just call it "contiguity"?

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


More information about the Mlir-commits mailing list