[Mlir-commits] [mlir] [MLIR][XeGPU][TransformOps] Add convert_layout op (PR #167342)

[Tuomas Kärnä]

================
@@ -161,4 +161,66 @@ def SetOpLayoutAttrOp : Op<Transform_Dialect, "xegpu.set_op_layout_attr", [
   }];
 }
 
+def ConvertLayoutOp : Op<Transform_Dialect, "xegpu.convert_layout", [
+  AttrSizedOperandSegments,
+  DeclareOpInterfaceMethods<MemoryEffectsOpInterface>,
+  TransformOpInterface
+]> {
+
+  let summary = "Convert xegpu.layout attribute for a value.";
+  let description = [{
+    Adds an `xegpu.convert_layout` op to convert the `xegpu.layout` attribute
+    of a value. First, the `xegpu.load_nd` producer op of the value is found.
----------------
tkarna wrote:

> Why not just follow exact the same xegpu.convert_layout semantics, which include both layout (from and to). So the implementation doesn't have to search for a load.

There are many ways in which the API could be designed. Here the question is whether we should include both input and output layouts to the `convert_layout` transform op, or just the output layout and infer the input layout from the producer chain. I see different options:

1. Require that producers have not been assigned a layout yet. In this case it would make sense for the `convert_layout` op to take both input and output layouts and assign them accordingly. Setting the producer layout, however, is not trivial, you'd need to trace the producer chain and decide what to do. Essentially this op would duplicate the roles of `set_desc_layout` and/or `set_op_layout_attr` transform ops. This does not sound like a good design.

2. Require that producers already have layouts. In this case, we could pass the input layout to the `convert_layout` op. The problem is that the user might pass a different layout that the producer chain actually uses, resulting in inconsistent layout config (which could fail only later on in the lowering pipeline - AFAIK op verifiers cannot check for consistency in all cases). To prevent this from happening we should verify that the passed input layout matches the layout of the producer. So we'd need to implement the producer layout discovery in any case, and now the user-defined input layout seems redundant. I do not see a use case where the user-defined input layout would be needed.

3. The present implementation: require that producers have layouts and infer that layout in the `convert_layout` op. Given the above reasoning this seems like the best choice IMO.

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