[all-commits] [llvm/llvm-project] 1fadc0: [MLIR][XeGPU] Fix order remapping in layout transp...

[Jianhui Li via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1fadc09c1985a6f3bb0ff993fc876384797116a3
      https://github.com/llvm/llvm-project/commit/1fadc09c1985a6f3bb0ff993fc876384797116a3
  Author: Jianhui Li <jian.hui.li at intel.com>
  Date:   2026-06-24 (Wed, 24 Jun 2026)

  Changed paths:
    M mlir/lib/Dialect/XeGPU/IR/XeGPUDialect.cpp
    M mlir/test/Dialect/XeGPU/propagate-layout-subgroup.mlir

  Log Message:
  -----------
  [MLIR][XeGPU] Fix order remapping in layout transpose (#205212)

LayoutAttr::transposeDims and LayoutAttr::isTransposeOf mishandled the
`order` field when transposing a layout. The `order` field is
fundamentally different from the size-valued fields (sg_layout, sg_data,
inst_data, lane_layout, lane_data): its values are dimension indices
(order[0] is the fastest-varying dim), not per-position sizes. The two
require different transpose rules:
    - Size fields — reindex by position: new[i] = orig[perm[i]]
- order — relabel values through the inverse permutation: newOrder[i] =
inversePerm[origOrder[i]]

Both functions incorrectly applied the size-field rule to `order`.
Because the bug was applied consistently in both places, it stayed
hidden for trivial/symmetric (e.g. 2D [1,0]) permutations, where the two
rules happen to coincide. It only surfaces for non-trivial permutations
such as the 3D [1,0,2] produced by a broadcast→transpose chain.
   
   Assist-by-Claude

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply at anthropic.com>



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications