[llvm-branch-commits] [mlir] [mlir][Transforms] Add 1:N `matchAndRewrite` overload (PR #116470)

Markus Böck via llvm-branch-commits llvm-branch-commits at lists.llvm.org
Sat Nov 16 02:05:55 PST 2024


================
@@ -1376,14 +1423,36 @@ void ConversionPatternRewriterImpl::insertNTo1Materialization(
     legalOutputType = replacements[0].getType();
   }
   if (legalOutputType && legalOutputType != originalType) {
+    UnrealizedConversionCastOp targetCastOp;
     Value targetMat = buildUnresolvedMaterialization(
         MaterializationKind::Target, computeInsertPoint(argMat), loc,
         /*inputs=*/argMat, /*outputType=*/legalOutputType,
-        /*originalType=*/originalType, converter);
+        /*originalType=*/originalType, converter, &targetCastOp);
+    if (targetCastOp)
+      nTo1TempMaterializations.insert(targetCastOp);
     mapping.map(argMat, targetMat);
   }
 }
 
+SmallVector<Value>
+ConversionPatternRewriterImpl::unpackNTo1Materialization(Value value) {
+  // Unpack unrealized_conversion_cast ops that were inserted as a N:1
+  // workaround.
+  auto castOp = value.getDefiningOp<UnrealizedConversionCastOp>();
+  if (!castOp)
+    return {value};
+  if (!nTo1TempMaterializations.contains(castOp))
+    return {value};
+  assert(castOp->getNumResults() == 1 && "expected single result");
+
+  SmallVector<Value> result;
----------------
zero9178 wrote:

Do I understand correctly that this recursion for scenarios such as `tuple<i32, tuple<i64>>` to flatten them properly? I think it might be worth leaving a comment here just in case. This also causes some of the major simplifications in the decompose-call-graph tests right?

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


More information about the llvm-branch-commits mailing list