[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