[RFC] Should We Restrict the Usage of 0-D Vectors in the Vector Dialect?

[banach-space]

Thank you for reviewing and providing detailed feedback, @MaheshRavishankar!

@MaheshRavishankar

I think we need to have two separate conversations.

1. Support for 0-D vectors in specific operations.
2. General support for 0D vectors.

Agreed. This RFC is intentionally limited to the first point.

My overarching goal is to improve the Vector dialect. Whether we ultimately decide to support or restrict 0-D vectors, there’s significant work needed to clarify semantics and reduce complexity. There’s already been great progress, so thanks to @Groverkss for these contributions:

• [mlir][Vector] Fix vector.extract lowering to llvm for 0-d vectors by Groverkss · Pull Request #117731 · llvm/llvm-project · GitHub
• [mlir][Vector] Add support for 0-d shapes in extract-shape_cast folder by Groverkss · Pull Request #116650 · llvm/llvm-project · GitHub
• [mlir][Vector] Fix vector.insert folder for scalar to 0-d inserts by Groverkss · Pull Request #113828 · llvm/llvm-project · GitHub

And @dcaballe has been tackling the unfortunate vector.extract/vector.insert verifier (thank you!):

• [mlir][vector] Add verification for incorrect vector.extract by dcaballe · Pull Request #115824 · llvm/llvm-project · GitHub

Despite this progress, the sheer number of edge cases remains a maintenance burden. To my knowledge, 0-D vector support does not address any compelling practical needs to justify this overhead.

@MaheshRavishankar

So in this sense I am -1 on having vector.extract/vector.insert disallowing 0D vectors.

To clarify, my proposal only restricts the non-indexed argument case. For instance, this remains valid:

%0 = vector.extract %src[] : f32 from vector<f32>
%1 = vector.insert %v, %dst[] : f32 into vector<f32>

@MaheshRavishankar

Tensor dialect supports 0D vectors. Since tensor → vector is one important path of targeting vector dialect, suddenly having vector dialect not support 0D vector seems like a gap.

1. Does the Tensor dialect’s support for 0-D tensors mean we must support 0-D vectors universally in Vector?
2. This RFC does not propose removing 0-D vector support entirely. The scope is far more limited.

@MaheshRavishankar

It adds complication everywhere vector dialect is used.

I disagree My experience suggests that supporting 0-D vectors introduces more complexity than not supporting them.

That said, I recognize this is a nuanced topic. 0-D vectors address some challenges but create others, such as the ambiguity described in my original post. The goal here is to start defining and enforcing semantics around 0-D vectors to better understand their role.

@MaheshRavishankar

Any transformation involving vector.extract will have to check for scalar type or vector type and handle it appropriately.

True, but conversely, there’s also substantial code checking:

if (vectorType.getRank() == 0)

This wouldn’t be there without 0-D vectors

Now, I do agree with you and your concerns. But I just have a feeling that we will discover that in practice this isn’t such an issue. The whole point of labelling this as an experiment is check and understand the impact. Right now I feel that this is my gut feeling versus yours

@MaheshRavishankar

It is true that LLVM for example does not handle 0-rank vectors. This can be easily handled during lowering to LLVM (which I think it does already)

Indeed, and I referenced the relevant LLVM code in my post (and provided an e2e example lowering to assembly). However, the point stands: Introducing 0-D vectors in one place necessitates their elimination elsewhere.

@MaheshRavishankar

vector.extract/vector.insert disallowing 0D vectors. It would also then be redundant with vector.extract_element/vector.insert_element while I think they serve different purposes.

Note that vector.extractelement and vector.insertelement are being removed:

• https://discourse.llvm.org/t/rfc-psa-remove-vector-extractelement-and-vector-insertelement-ops-in-favor-of-vector-extract-and-vector-insert-ops/

As mentioned in my RFC:

@banach-space

Note: This RFC will be coordinated with the one above to ensure progress on one does not block the other.

---

Final thoughts:

1. This RFC is not about removing 0-D vectors.
   • It’s about understanding where they solve problems and assessing whether their complexity is justified.
   • The patchy current support makes it hard to evaluate their role properly.
2. Ubiquitous support for 0-D vectors is neither good nor necessary, IMO.
   • However, to explore the problem space, we need to experiment.

Thank you
-Andrzej