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

Mehdi Amini llvmlistbot at llvm.org
Wed Nov 22 21:22:00 PST 2023


joker-eph wrote:

> The way I'm thinking about transpose is that in addition to moving data, it does a structured transformation of the metadata (type). Shape cast asserts no data movement, but is relatively unstructured in terms of how the metadata is being transformed.

That's a good point! But:
1) If (and that's a big "if" considering @nicolasvasilache's comment that needs to be addressed first), the op is designed around "no data movement": there is a limit to the "unstructureness" though? We're not talking about going from a "structured relationship" to "arbitrary" (basically to take your example before, we end up with the kind of guarantees that the map simplifies down to `(0, d0)`  the same way somehow, if we inject correctly the dimensions here).
- Is <Nx1> -> <1xN> really a transpose? I can see that you can describe the transformation on the shape as a transpose, but that seems fairly arbitrary to me to try to stick to "transpose" instead of, for example, contract_shape / expand_shape (or whatever doing `<Nx1>` -> `<N>` -> `<1xN>` would be named). 
Is what you'd want in this case is an `affine_shape_cast` where the cast isn't "arbitrary" (not that it is here either) but encoded with an affine map? That is something like `%1 = vector.reshape : vector<1x4xf32> with (d0, d1) -> (d1, d0) to vector<4x1xf32>`? The map can be arbitrary as long as it is consistent with the "no data movement aspect". 
(now by your argument, a map is also somehow "unstructured" compared to a "transpose" ;) ).


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


More information about the Mlir-commits mailing list