This is an archive of the discontinued LLVM Phabricator instance.

[mlir] [VectorOps] Introduce vector.transpose
ClosedPublic

Authored by aartbik on Mar 19 2020, 4:01 PM.

Details

Summary

Introduced in order to introduce specialized lowering passes that implement transposition operations efficiently.

Diff Detail

Event Timeline

aartbik created this revision.Mar 19 2020, 4:01 PM
aartbik updated this revision to Diff 251496.Mar 19 2020, 4:15 PM

fixed accidentally removed line

Thanks Aart. How hard would this be to generalize this op to make it N-D transpose op, instead of limit to 2D cases? For example, I may want to transpose the inner two dimensions of a N-D vector

Thanks Aart. How hard would this be to generalize this op to make it N-D transpose op, instead of limit to 2D cases? For example, I may want to transpose the inner two dimensions of a N-D vector

Not very hard for the reference implementation (so the direct lowering into a bunch of extra/insert operations), but a lot harder for efficient implementations.
Would you rather that I lift the restriction on 2-D right now already and provide a reference lowering for all ranks and sizes?
(happy to do that)

Thanks Aart. Yes, if its not too much work, I'd love to see this op take a permutation of dimensions of an N-D vector.

However, if you are concerned about having to support lowerings for all permutations, then how about removing the restriction on the operand being 2-D vectors, but limit the transpose op to picking a single pair of dimensions to transpose.

For example:

func @transpose(%arg0: vector<3x4x11x7xi32>) -> vector<3x4x7x11xi32> {

%0 = vector.transpose %arg0, 2, 3 : vector<3x4x11x7xi32>
return %0 : vector<3x4x7x11xi32>

}

Thanks!

Thanks Aart!

@andydavis1 if you don't mind, I'd like to go DFS on the 2-d transpose and connect it all the way to the LLVM intrinsics from this state.
We have short-term use/benchmarking cases for it.

I think it is easy to extend the op semantics now and have the matcher fail on the non-2-D case.
How do we want to represent permutation? AffineMapAttr or I32ArrayAttr?

limit the transpose op to picking a single pair of dimensions to transpose

This will still be tricky because we'll have a bunch of slices etc.
I'd just go with fail if not a 2-D op so that the lowering remains very simple towards LLVM matrix intrinsics (for now).

How do we want to represent permutation? AffineMapAttr or I32ArrayAttr?

If we go the route of general semantics and dimensions, I think arrayattr would the the right syntax

%1 = vector.tranpose %0 [0,1,3,2] : vector<2x3x4x5xf32>

<----->
  rank-length, all members 0 <= i < rank, proper permutation

It will not be much more work to introduce this syntax, and still verify for proper 2-D transpose (or only lower those for the time being).

WDYT? Right syntax, shall I do it?

mlir/lib/Dialect/Vector/VectorOps.cpp
1534

Drop all this and use assemblyFormat instead please.
See: https://reviews.llvm.org/D75987 for the usage of TypesMatchWith for dependent types.

WDYT? Right syntax, shall I do it?

Sure go for it, it is intuitive enough IMO.

aartbik marked an inline comment as done.Mar 20 2020, 11:46 AM
aartbik added inline comments.
mlir/lib/Dialect/Vector/VectorOps.cpp
1534

Yes, the sole purpose of having this as C++ was to compute the type dependence. But from this feedback, I am guessing we can express this in *.td now also. Cool! Let me look into that and make the change.

aartbik updated this revision to Diff 251759.Mar 20 2020, 2:14 PM

generalized to n-D vectors, more invalid tests

aartbik retitled this revision from [mlir] [VectorOps] Introduce vector.transpose on 2-D vectors to [mlir] [VectorOps] Introduce vector.transpose.Mar 20 2020, 2:15 PM
aartbik edited the summary of this revision. (Show Details)
nicolasvasilache accepted this revision.Mar 20 2020, 3:19 PM

Thanks Aart!

This revision is now accepted and ready to land.Mar 20 2020, 3:19 PM
rriddle added inline comments.Mar 20 2020, 4:08 PM
mlir/include/mlir/Dialect/Vector/VectorOps.td
1284

Please make sure that you use mlir code blocks for descriptions.

mlir/lib/Dialect/Vector/VectorOps.cpp
1538

nit: Prefer using llvm::SmallBitVector or llvm::BitVector.

This revision was automatically updated to reflect the committed changes.
aartbik marked 2 inline comments as done.Mar 20 2020, 5:26 PM
aartbik added inline comments.
mlir/include/mlir/Dialect/Vector/VectorOps.td
1284

You mean

block

right? If so, we seem to have been a bit inconsistent with that anyway.
Follow up coming....

mlir/lib/Dialect/Vector/VectorOps.cpp
1538

noted, will follow up