[Mlir-commits] [mlir] [mlir][xegpu] Lower lane_data repack convert_layout to bitcast_shuffle (PR #210837)

[Artem Kroviakov]

https://github.com/akroviakov commented:

The sequence of `bitcast -> bitcast_shuffle -> bitcast` seems excessive. If the true goal is to do the shuffle, why not let the bicast be an implementation detail (i.e., have the surrounding bitcasts as part of the lowering itself)?

The i32 vs vector<2xi16> distinction seems to be enforcing the contiguity encoding into the type, which should not matter at the output of sg-to-lane, where we do not expect any further layout context. 
It appears that this distinction tries to carry the layout info into the lane-level xegpu to let the op *lowering* reason about whether the case of `vector<2xi16> -> vector<2xf16>` is a repack+bitcast or a plain bitcast.

I think the lane ownership changes should be decided at the distribution stage, not inferred by the op lowering.

Please correct me if I misunderstood the current op design/intent.

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