[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