Adds supprot for vector unroll transformations to unroll in different
orders. For example, the vector.contract can be unrolled into a
smaller set of contractions. There is a choice of how to unroll the
decomposition based on the traversal order of (dim0, dim1, dim2).
The choice of traversal order can now be specified by a callback which
given by the caller of the transform. For now, only the
vector.contract, vector.transfer_read/transfer_write operations provide
support for the callback.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thomas had some comments from offline discussion (paraphrase)
- The functor utility DecomposeShapeIterator is more efficient but we could just use getVectorOffset be pre-permuting the shapes.
Personally I feel that the functor utility is more readable than the getVectorOffset which links into helper functions in a different file. Can we keep this and then slowly remove the getVectorOffset utility?
- Add vector.transfer_read/transfer_write support in this commit as well?
Thanks! Looks good to me, I added few style related comments.
mlir/lib/Dialect/Vector/Transforms/VectorUnrollDistribute.cpp | ||
---|---|---|
92 | I think having an explicit function name would make it easier to read the code than overloading operator(). | |
mlir/test/lib/Dialect/Vector/TestVectorTransforms.cpp | ||
522 | nit: skip braces on single line if: |
Hi, just for heads-up, this change caused many failures in IREE tests including compilation errors and accuracy errors.
Ok, thanks. Do you mean C++ compilation or mlir compilation errors?
There were build failures on some configs/compilers that I fixed with one-line change a392a39f75af [mlir][vector] fix typo in vector unroll transform.
Do we need t o revert?
Let me know if you can share the compilation/accuracy errors.
It would be nice if you don't mind reverting.
There are compilation errors in compiling some mlir sources. There is a crash too.
The PR for integration: https://github.com/google/iree/pull/9369
(You can find the failing tests there.)
Ok yeah definitely looks like I made a mistake somewhere. I'll revert now, thanks for sharing those tests
I think having an explicit function name would make it easier to read the code than overloading operator().