[Mlir-commits] [mlir] [mlir][xegpu] Fix operand layouts when rematerializing on layout conflict (PR #224730)
Jianhui Li
llvmlistbot at llvm.org
Thu Oct 1 16:52:16 PDT 2026
================
@@ -1652,6 +1652,36 @@ LogicalResult ResolveLayoutConflicts::assignResultLayout(OpResult &result) {
return success();
}
+// Recursively rematerialize a trivially-rematerializable producer subtree so
+// that the clone yields `layout`. Cloning only the producer would leave its
+// operands pointing at values that carry the original (conflicting) layout,
+// making the clone's operand and result layouts disagree. Stamp `layout` on the
+// clone and rematerialize each vector operand with the layout back-derived from
+// it.
+static Value rematerializeWithLayout(OpBuilder &builder, Value value,
+ xegpu::DistributeLayoutAttr layout) {
+ Operation *producerOp = value.getDefiningOp();
+ builder.setInsertionPointAfter(producerOp);
+ Operation *clone = builder.clone(*producerOp);
+ OpResult cloneResult = clone->getResult(0);
+ // Drop the inherited producer layout so the new layout takes effect.
----------------
Jianhui-Li wrote:
what do you mean "the new layout takes effect"? These layout on these rematerializable ops are temproary layout will be recovered in the beginning of distribution process anyway.
https://github.com/llvm/llvm-project/pull/224730
More information about the Mlir-commits
mailing list