[Mlir-commits] [mlir] [mlir][vector] Add verification for incorrect vector.extract (PR #115824)
Diego Caballero
llvmlistbot at llvm.org
Sat Nov 16 18:46:45 PST 2024
================
@@ -1339,6 +1339,50 @@ bool ExtractOp::isCompatibleReturnTypes(TypeRange l, TypeRange r) {
return l == r;
}
+// Common verification rules for `InsertOp` and `ExtractOp` involving indices.
+// `indexedType` is the vector type being indexed in the operation, i.e., the
+// destination type in InsertOp and the source type in ExtractOp.
+// `vecOrScalarType` is the type that is not indexed in the op and can be
+// either a scalar or a vector, i.e., the source type in InsertOp and the
+// return type in ExtractOp.
+static LogicalResult verifyInsertExtractIndices(Operation *op,
+ VectorType indexedType,
+ int64_t numIndices,
+ Type vecOrScalarType) {
+ int64_t indexedRank = indexedType.getRank();
+ if (numIndices > indexedRank)
+ return op->emitOpError(
+ "expected a number of indices no greater than the indexed vector rank");
+
+ if (auto nonIndexedVecType = dyn_cast<VectorType>(vecOrScalarType)) {
+ // Vector case, including:
+ // * 0-D vector:
+ // * vector.extract %src[2]: vector<f32> from vector<8xf32)
----------------
dcaballe wrote:
You are looking at it from the dimensionality perspective. I'm looking at it from the number of elements perspective. The first case is extracting a vector with one element from a vector with one element, which is redundant. The second case is extracting a vector with one element from a vector with 8 elements, which is a meaningful operation.
We could let the first case to be valid as well but it's a redundant operation that can't be trivially folded. If we remove the `vector.extract` and propagate the `vector<1xf32>` source vector forward, there would be a type mismatch because a single element 1-D vector type is not a 0-D vector. We would have to introduce a canonicalization pattern that turns that `vector.extract` into a bitcast or something like that.
https://github.com/llvm/llvm-project/pull/115824
More information about the Mlir-commits
mailing list