[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