[Mlir-commits] [llvm] [mlir] [Linalg] Fix crash in vectorizeScalableVectorPrecondition with undersized vector sizes (PR #205493)

Ege Beysel llvmlistbot at llvm.org
Thu Jul 30 03:14:13 PDT 2026


================
@@ -2381,6 +2381,18 @@ vectorizeScalableVectorPrecondition(Operation *op,
     return success(isa<linalg::UnPackOp>(op));
   }
 
+  // Ensure that the number of vector sizes and scalable flags provided by the
+  // user does not exceed the number of loops in the target Linalg op.
+  // Accessing iterator types with an out-of-bounds index would cause an
+  // assertion failure (SmallVector::operator[]). This check converts such a
+  // crash into a clean failure, allowing the transform interpreter to report
+  // an error gracefully.
+  // Regression test:
+  // mlir/test/Dialect/Vector/transform-op-vector-to-llvm.mlir
+  if (inputScalableVecDims.size() > linalgOp.getNumLoops() ||
+      inputVectorSizes.size() > linalgOp.getNumLoops())
----------------
egebeysel wrote:

Agreed. You can assert this in the vectorizer itself, but I don't think this should be a _pre-condition_ of (scalable) vectorization.

On another note, do we actually have use-cases for when the provided vector sizes are less than the num loops? I can think of unit dimensions maybe being an exception here, but are there other examples where a stricter equality is not required? @banach-space 

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


More information about the Mlir-commits mailing list