[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