I’m curious how you see this - dialects in MLIR can use the builtin types to mean anything - it would be weird, but it would be fine to implement yourdialect.fadd that works on i32 types for example. This sort of use-case puts pressure on the builtin types to expand to support an extended variety of use-cases that might not align with other clients.
One challenge of expanding the representation of the builtin types is that it becomes more difficult to reason about invariants: if you expand the flexibility of a type (e.g. when IntegerType got signedness information, or when Tensor/memref got layout) EVERY pass and dialect that uses that type needs to rationalize what the additional information means for them - at the very least they should intentionally reject unsupported stuff, but in many cases, new bugs are introduced.
The current VectorType is pretty hard associated with hardware vector registers or higher level abstracts that get directly decomposed into them. Adding layout abstraction information seems like a pretty significant departure from what effectively all the existing clients and dialects using this type would want or expect.
While I understand that it can be locally convenient to extend the builtin types to add new bells and whistles, doing so adds expense (either in terms of defensive checks or in future-bugs/non-composability/technical debt) to all the other clients.
I understand that you’re currently using VectorType to use a much more abstracted value-semantic concept (perhaps more similar to a tensor) than any of the other clients. That said, given that MLIR makes it really easy to define your own types, and has interfaces that allow Ranked types like to to be fairly interchangable with the ecosystem, have you considered just defining a yourdialect.vector type? Alternatively, have you considered using the builtin tensor type which does exactly what you’re looking for?
That seems less invasive, and would impose less burden on all the clients of the existing types. I’ll note that the proposed patch extends the type but doesn’t add any of /handling/ of the new field to any of the existing clients of this type.
-Chris