[Mlir-commits] [mlir] [mlir][xegpu] Distribute three more convert_layout cases to lanes (PR #222693)

Sang Ik Lee llvmlistbot at llvm.org
Fri Sep 11 14:48:23 PDT 2026


================

----------------
silee2 wrote:

Renamed to `hasDefaultOrderAndUnitLaneData`.
>
> I checked for an existing helper first: there is none — not on `LayoutAttr`/`SliceAttr`, not on the `DistributeLayoutAttr` interface, not in `XeGPUUtils`. The only default-order logic lives inside `getEffectiveOrderAsInt()`, which synthesizes `[rank-1, ..., 0]` when `order` is unset, and no other caller compares an effective order against that default (the only other comparisons are input-vs-target equality in `SgToLaneConvertLayout`), so this is the single user of the condition today.
>
> I avoided `isDefaultLayout` because only half of it is about defaults: unset `order` does mean default order, but unset `lane_data` makes `getEffectiveLaneDataAsInt()` return an empty vector, so the unit-`lane_data` half requires an explicit `[1, 1]` and intentionally rejects layouts with no `lane_data` (they are not lane-level layouts). `isDefaultLayout` would also suggest something about `lane_layout`/`inst_data`, which the predicate deliberately does not constrain.
>
> Would you like the reusable half hoisted? I can add `bool hasDefaultOrder()` next to `getEffectiveOrderAsInt()` on `DistributeLayoutAttr` — it works for `SliceAttr` too, since that projects the parent order — and reduce this helper to `rank == 2 && hasDefaultOrder() && lane_data == [1, 1]`. Happy to do it in this PR if you think it belongs on the interface; otherwise I'll leave it local until a second user shows up.

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


More information about the Mlir-commits mailing list