[Mlir-commits] [mlir] [mlir][linalg] Preserve unsigned integer widening in named contraction vectorization (PR #216283)

Chuanqi Xu llvmlistbot at llvm.org
Sun Aug 23 22:51:07 PDT 2026


================
@@ -2069,6 +2069,29 @@ vectorizeAsLinalgContraction(RewriterBase &rewriter, VectorizationState &state,
     vecOperands.push_back(read);
   }
 
+  bool hasUnsignedCast =
+      TypeSwitch<Operation *, bool>(linalgOp.getOperation())
+          .Case<MatmulOp, BatchMatmulOp, BatchReduceMatmulOp, ContractOp>(
+              [](auto op) { return op.getCast() == TypeFn::cast_unsigned; })
+          .Default(false);
+  if (hasUnsignedCast) {
+    auto accType = dyn_cast<VectorType>(vecOperands[2].getType());
+    auto accElementType =
+        accType ? dyn_cast<IntegerType>(accType.getElementType()) : nullptr;
+    if (accElementType && accElementType.isSignless()) {
+      for (Value &operand : MutableArrayRef(vecOperands).take_front(2)) {
+        auto operandType = cast<VectorType>(operand.getType());
+        auto operandElementType =
+            dyn_cast<IntegerType>(operandType.getElementType());
+        if (!operandElementType || !operandElementType.isSignless() ||
+            operandElementType.getWidth() >= accElementType.getWidth())
+          continue;
+        operand = arith::ExtUIOp::create(
----------------
ChuanqiXu9 wrote:

> but IMHO we should always start with what's available instead of adding new functionality.

Yeah, agreed. this is the reason why I give a LGTM.

> What optimization capabilities are you referring to?

The optimization to optimize the extui out.

> Is there a target that would be harmed by this?

No, I just think currently it is suboptimal in the abstract mind model.

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


More information about the Mlir-commits mailing list