[Mlir-commits] [mlir] [mlir][linalg] Preserve cast semantics during generic to matmul (PR #174757)
Adam Siemieniuk
llvmlistbot at llvm.org
Fri Jan 9 00:06:24 PST 2026
================
@@ -131,17 +132,75 @@ static IndexMatchResult matchOperandMap(AffineMap map, unsigned rowDimIdx,
}
// Replaces genericOp with `NamedOpTy` op, supplied as a template arg.
-// All the variants expressed as pseudo regular expression:
-// `linalg.{batch_}?matmul{_transpose_a | _transpose_b}?`
-// have same number of ins/out, so its easy to stamp different versions.
+// All the variants expressed as pseudo regular expression:
+// `linalg.{batch_}?matmul{_transpose_a | _transpose_b}?`
+// have same number of ins/out, so its easy to stamp different versions.
+// `castTy` is an optional type function that indicates whether (and which) cast
+// attribute is needed for the named matmul op.
template <typename NamedOpTy>
-static LinalgOp replaceWithMatmulVariant(RewriterBase &rewriter, GenericOp op) {
+static LinalgOp replaceWithMatmulVariant(RewriterBase &rewriter, GenericOp op,
+ std::optional<TypeFn> castTy) {
+ SmallVector<NamedAttribute> castAttrVec;
+ // Only explicitly specify the cast attribute if the cast type exists and is
+ // pointing to unsigned cast (the default is signed cast for
+ // linalg.matmul/linalg.batch_matmul).
+ if (castTy.has_value() && *castTy == TypeFn::cast_unsigned)
----------------
adam-smnk wrote:
`cast` attribute has a default value, however, it's implicit and normally the attribute is not printed.
It wouldn't hurt assigning it here but it'd make IR more verbose and slightly different in case of roundtrip (linalg with implicit cast -> linalg with explicit cast). Although, it'd make the code more robust/generic as you mention.
Right now, I'm fine with either approach.
Ideally, I'd go for assigning attribute here and improving linalg's pretty printing to omit default valued cast attr (same as it is done today for indexing maps for matmul etc.).
Of course, I'd address all that in a separate PR.
https://github.com/llvm/llvm-project/pull/174757
More information about the Mlir-commits
mailing list