[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