[Mlir-commits] [mlir] [mlir][vector] Add verification for incorrect vector.extract (PR #115824)

Andrzej Warzyński llvmlistbot at llvm.org
Thu Nov 21 13:34:42 PST 2024


banach-space wrote:

> I feel that 0-d vectors are being singled out as though somehow being a non-canonical way to represent a single element vector is grounds for removal. I'd argue that `vector<1x...x1xf32>` is equally uncanonical in that case.

You are raising a very good point.

I'm not sure I'd use the term "non-canonical" in this sense, but in principle I agree - there's many ways to represent a 1-element vector. Note, however, that in practice, only 0-D vectors require special treatment. IMHO, we can make our lives much easier if e.g. we start restricting Vector ops to:

* Either always require a scalar when only one element is needed, or, at minimum,
* Require `vector<1xi32>` where `vector<i32>` might also currently be acceptable.

If such restrictions turn out to be too limiting in some cases, then I’d agree we shouldn’t pursue them. However, I’ve yet to encounter examples where this would be a real blocker.

One case where this kind of restriction could simplify things comes from:

* https://github.com/llvm/llvm-project/pull/116526, and
* https://github.com/llvm/llvm-project/issues/116197.

Specifically, consider the question: What should the type of a 1-element mask be? `vector<1xi1>` or `vector<i1>`? As discussed in the PR, the answer isn’t always “inferable” from the vector being masked (e.g., due to broadcast dimensions). While alternative fixes might address this, I believe making certain vector operations more restricted - where practical - could help remove ambiguities and reduce special cases. Of course, this should only be pursued if it doesn’t block anyone’s use cases.

----

Anyway, this is tangential to this PR and lets wait for Diego to update it :)

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


More information about the Mlir-commits mailing list