[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