[Mlir-commits] [mlir] [mlir][xegpu] Lower lane_data repack convert_layout to bitcast_shuffle (PR #210837)
Artem Kroviakov
llvmlistbot at llvm.org
Thu Jul 30 09:48:07 PDT 2026
akroviakov wrote:
> If we hide bitcast, we won't be able to express the intent
AFAIU, the intent is a redistribution that is expressed in the incoming layouts. After sg-to-lane the "intent" should be resolved into an explicit op without needing further type-dependent inference during lowering.
> It has no intent to carry layout info into lane-level xegpu
> 4xi16 and i64 encode different meaning of the data distribution to lanes
Exactly, my question is why the encoding matters at the lane level if xevm can reinterpret (re-pack) it anyway to match an intrinsic, and there is no distribution below sg-to-lane that could leverage the meaning?
> xegpu.bitcsat_shuffle: vector<4xbf16> to vector<4xbf16> //lost the data redistribution semantics
What compels us to choose the type as the right place to express that semantics, instead of the operation (a fixed-behavior primitive)?
https://github.com/llvm/llvm-project/pull/210837
More information about the Mlir-commits
mailing list