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

[llvmlistbot at llvm.org]

MaheshRavishankar wrote:

> I also look at it the other way, "what is the more canonical form that performs the exact same operation?":
> 
> 1. `%1 = vector.transpose %0 [1, 0] : vector<1x4xf32> to vector<4x1xf32>`
> 2. `%1 = vector.shape_cast : vector<1x4xf32> to vector<4x1xf32>`
> 
> Do you believe that 1 is more canonical than 2? Considering that `vector.shape_cast` is an operation that is more restrictive than `vector.transpose` and provide better guarantees (no data movement), I would wage that 2) is a winner here.

@qedawkins gave a more comprehensive answer (Thanks!), but I do believe (1) is a more canonical representation. It is effectively carry more information about what the program is doing. With `shape_cast` to understand that this is a transpose you have to look at the dimensions of the source and destination and somehow figure out this is a transpose (in general I dont think this is possible). I suspect the reason for this lowering is that by default `vector.transpose` lowers to LLVM using a sequence of `vector.insert/extract` (which also works on SPIR-V). Conversion to `vector.shape_cast` is a more efficient lowering for LLVM since LLVM supports multi-dimensional vectors. This doesnt work for SPIR-V since it does not support multi-dimensional vectors. So on the SPIR-V path you will need to "recognize" that this is a transpose and do a similar lowering. This is another indication that `vector.transpose` is actually a more canonical representation of the computation. The conversion to `shape_cast` seems to be motivated by more efficient LLVM lowering, so it should be used on the LLVM lowering path. 



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