I think the conclusion is that having a VectorType where the shape matches the actual shape of the vector would require disconnecting VectorType from ShapedType, as ShapedTypes won’t support scalable dimensions.
For this new VectorType dimensions could be represented by llvm::ElementCount (or some new MLIR type to allow extending it to cover other size types, e.g. dynamic vectors).
This is just a possibility, that I may try sometime in the future (but no solid plans to do so). Also, I’d be happy to collaborate on this (or review patches) if anyone picks this up in the meantime.
I’ve implemented an alternate solution that makes VectorType safer and easier to use w.r.t. scalability, without changing any other ShapedTypes. It adds new scalability-safe builders, accessors, and iterators to VectorType , which can be used instead of the unsafe methods from ShapedType (which cannot be removed as long as VectorType is a ShapedType).
The idea is this new interface makes scalability an intrinsic part of a vector dimension, not something that can be easily dropped, or forgotten. It should also make common operations easier and more readable.
Here are a few examples of how things look when using this API:
// Check if the back dim is 1:
vectorType.getDims().back() == VectorDim::getFixed(1)
// Loop over dims:
for (VectorDim dim : vectorType.getDims()) {
// ...
}
// ...works with standard helpers too
for (auto [i, dim] : llvm::enumerate(vectorType.getDims()) {
// ...
}
// Trim leading 1 dims:
VectorType::get(f32, vectorType.getDims().dropWhile([](VectorDim dim){
return dim == VectorDim::getFixed(1);
}));
// Check vectorType is [4]x[4]
vectorType.getDims() == { VectorDim::getScalable(4), VectorDim::getScalable(4) }
// Unsafe integer comparison:
// Does not compile!
// You cannot implicitly convert a VectorDim to an integer!
// You must specify if your quantity is fixed or scalable!
vectorType.getDim(2) == 5 // bang!