[Mlir-commits] [mlir] [mlir][Vector] Add support for 0-d shapes in extract-shape_cast folder (PR #116650)

[llvmlistbot at llvm.org]

MaheshRavishankar wrote:

> > We can discuss on the RFC, but I think we need to have support for 0D vector. Without that the system doesnt seem to be closed. For example, tensor and memrefs allow 0D vectors, but having vectors being an outlier and not supporting 0D vector seems like a gap.
> 
> Thank you for pointing this out! I think it would be helpful to provide concrete examples where avoiding `0D` vectors would lead to practical issues. That would clarify why maintaining consistency with memref and tensor is so critical in this case.

Agreed. We should collect examples where havig 0D vectors is useful, but a better place might be in response to the RFC.

> 
> That said, I wonder if strict consistency across these types is always desirable. After all, the reason for having different types (e.g., tensor, memref, vector) is to capture distinct use cases and abstractions, right?
> 
> Personally, I see a different kind of inconsistency here. The ability to represent a scalar element in multiple ways (`f32` vs `vector<f32>` vs `vector<1xf32>`) introduces a lot of ambiguity. In my view, requiring `f32` instead of `vector<f32>` throughout the Vector dialect might simplify the system. This would reduce special-casing, avoid potential confusion, and ultimately improve the health and maintainability of the dialect.

Quick though here is that f32 and vector<f32> shouldnt matter in the end, but in the vector dialect itself if we dont have vector<f32> and instead rely on f32, it will cause a lot of bloat to keep the type consistent. For example some operations might be defined as operating on vector operands, but if a producer generates a f32 value there will be IR that is generated just to put the f32 into a vector<1xf32> , which is unnecessary. It just introduces artifacts into the code that makes analysis and transformations harder. Operations that "reduce" vectors could now generate a vector value or a scalar value depending on how the reduction is done (or IMO the worse solution of vector<1x1x...f32>).  If the vector dialect is consistent in always generating vector types, and the lowering from vectors handles vector<f32>  as effectively an f32, that seems to be the most consistent handling IMO.  Sorry, I am prefetching some discussion that will happen again on the RFC, but food for thought :) 


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