[Mlir-commits] [mlir] [mlir][vector][docs] Document indexed vs. non-indexed arguments (PR #130141)

[Andrzej Warzyński]

banach-space wrote:

Hey folks, thank you for your generous feedback!

We’ve over-indexed (pun not intended) on just one part of this PR:
1. **"Current operand naming is inconsistent; we should fix it"** → I’ve moved this to [Issue #131602](https://github.com/llvm/llvm-project/issues/131602) (thanks @qedawkins for the suggested renaming).
2. **"We are missing terminology in `Vector`; here’s one suggestion."** ← This PR!

My bad for not documenting this PR more clearly and for clustering two topics together—lesson learned! Kind request: let’s focus on **Part 2** 🙏🏻 (while moving **Part 1** to [#131602](https://github.com/llvm/llvm-project/issues/131602)).

Now, I’d still like us to discuss the **split into "indexed" and "non-indexed" arguments**. In my view, there’s a **gap in our terminology**, which becomes apparent when discussing operand constraints. Two recent examples:
- [PR #115824](https://github.com/llvm/llvm-project/pull/115824)
- [RFC: Should We Restrict the Usage of 0-D Vectors in the Vector Dialect?](https://discourse.llvm.org/t/rfc-should-we-restrict-the-usage-of-0-d-vectors-in-the-vector-dialect/)

While adding new terminology won’t **automagically** unblock those conversations, I do believe that **a richer and more precise vocabulary** will help us **articulate and disambiguate** our points. Specifically:
- **"Indexed"** → An operand that **must be a `vector`**.
- **"Non-indexed"** → An operand that **can be a `vector` but doesn’t have to be**.

I spent quite a few cycles reviewing Diego’s [PR #115824](https://github.com/llvm/llvm-project/pull/115824) and found the split into "indexed" and "non-indexed" operands quite illuminating.

Last, but not least, the actual taxonomy is secondary IMO. It's the standarisation that I am more interested in. 

Thanks for taking a look!
-Andrzej

https://github.com/llvm/llvm-project/pull/130141