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

[llvmlistbot at llvm.org]

================
@@ -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());
----------------
Pecco-314 wrote:

Yes, this can fail. At this point, the accumulator is known to be a signless integer, but cast_unsigned also permits floating-point operands and represents the conversion as `fptoui` (see [this](https://github.com/llvm/llvm-project/blob/main/mlir/test/Dialect/Linalg/generalize-named-polymorphic-ops.mlir#L109-L119)).

The current patch only handles integer widening, but materializing a vector `fptoui` here would be straightforward. I can extend this patch to cover that case as well if you prefer.

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