The vector.extract folding patterns do not support 0-D vectors
(actually, 0-D vector support couldn't even be implemented as a folding
pattern as it would require replacing vector.extract with a
vector.extractelement op). This patch is bailing out folding when 0-D
vectors are found.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Note that ExtractOp does not support 0-D vectors at this time.
It seems to me that all these checks could be defensive asserts.
Separately, we may consider extending ExtractOp to support 0-D vectors, which would make sense given that ExtractElement returns elemental types, but we'll also need tests.
Good point! I can turn the check on ExtractOp into an assert. The key check, though, is the one on the defining op. That one may have 0-D vectors and we may end up creating a 0-D ExtracOp as a result of the folding. That's what the patch is aim to prevent.
mlir/lib/Dialect/Vector/IR/VectorOps.cpp | ||
---|---|---|
1625–1628 | Can we move it after 0-D vectors check, then we are sure that the dest type is VectorType? We can still use cast and the cast has assertion semantics -- which is good to me. In the context, the dest type must be a vector type because input operand type is not a 0-D vector. |
Adding test. Some case can't be tested because other canonicalization patterns get in the way.
Can we move it after 0-D vectors check, then we are sure that the dest type is VectorType? We can still use cast and the cast has assertion semantics -- which is good to me.
In the context, the dest type must be a vector type because input operand type is not a 0-D vector.