[Mlir-commits] [mlir] [mlir][vector] Add vector.transpose with unit-dim to vector.shape_cast pattern (PR #72105)

[Diego Caballero]

dcaballe wrote:

Having a optional `populate*Patterns` sounds good to me (it has pros and cons, though) and I generally agree with the comments above. Let's do that then! 

Adding to Lei's comments, I'm more concerned about having specific limitations of a compiler backend creep on the generic layers of the stack. I think we should aim for certain level of completeness in all the backends when it comes to supporting these common layers. If there is no way to lower/legalize `vector.shape_cast` in SPIR-V we should definitely revisit that op altogether. Many ops in the vector dialect were heavily influenced by LLVM and we have been doing quite some work trying to generalize them. SPIR-V should play an important role in this task. Having backends supporting subsets of these generic dialects would be a catastrophic outcome IMO.

Regarding #3, I think the problem is bigger than `vector.shape_cast` as we have too many ways of representing the same thing and no specific canonical form. For the particular case discussed here I can thing of `vector.shape_cast`, `vector.broadcast`, `vector.extract/insert`, `vector.extract_element/insert_element` and `vector.transpose`. All of these alternatives have different canonicalization patterns and gaps so depending on which one we choose and how lucky we are we may end up with a more or less efficient code at the end. We should think about how to improve all of these and unify both the representation of some of these special cases (e.g., unit dim collapse/expansion) and their respective canonicalization patterns/lowerings.

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