This patch teaches isProjectedPermutation and inverseAndBroadcastProjectedPermutation
utilities to deal with maps representing an explicit broadcast, e.g., (d0, d1) -> (d0, 0).
This extension is needed to enable vectorization of such explicit broadcast in Linalg.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/IR/AffineMap.cpp | ||
---|---|---|
498–526 | Does that mean (d0, d1) -> (0, 0) would be a projected permuation? That doesn't sound right. |
Could you please verify if all tests still pass? For example, we might need to modify applyPermutationMap in AffineMap.h.
template <typename T> SmallVector<T> applyPermutationMap(AffineMap map, llvm::ArrayRef<T> source) { assert(map.isProjectedPermutation()); assert(map.getNumInputs() == source.size()); SmallVector<T> result; result.reserve(map.getNumResults()); for (unsigned i = 0, e = map.getNumResults(); i < e; ++i) { /* fix if (auto expr = map.getResult(i).dyn_cast<AffineConstantExpr>()) { result.push_back(0); continue; } */ unsigned dim = map.getDimPosition(i); result.push_back(source[dim]); } return result; }
I have something similar locally but I am not clear this is actually needed for now.
Would you mind holding off a bit until I clear up my stack and avoid conflicts?
Good catch! Yes, I had run all the lit tests and nothing failed. I fixed this, thanks!
Sure, I'll wait for you. After looking at your code, I'm addressing the review comments since they will also apply to your code.
mlir/lib/IR/AffineMap.cpp | ||
---|---|---|
498–526 | Good point! Note that this utility, not sure if intentionally, is already returning true for (d0, d1) -> (). (d0, d1) -> (0, 0) would be the equivalent preserving the dims. I think it boils down to what the definition of "projected permutation" is. I asked @nicolasvasilache and it seems to be ok to have zeros in a projected permutation. We could add logic to skip (d0, d1) -> () and (d0, d1) -> (0, 0) but they look like a valid corner case to me. WDYT? |
mlir/lib/IR/AffineMap.cpp | ||
---|---|---|
498–526 | In my mind projected permutation meant it has a permutation of the input dimensions and some dimensions may be missing (projection), so (d0, d1) -> () sounds like a valid projected permutation but having zeros instead of dimensions seems a bit odd. @nicolasvasilache is the referenced so if he thinks it is correct to allow extra zeros it is fine with me but this seems less intuitive to me. |
My stack is now flushed, feel free to land this @dcaballe and thanks for your patience!
Well technically, orthogonal projection of a vector v=(v0, .. vn) on the canonical axis e_k is the vector v=(v0, .. 0_k .. vn).
So far we have liberally jumped the gun a bit by also dropping those dimensions so that other invariants agree.
This LGTM; I would just make the behavior optional with a flag to avoid surprises (for now).
Does that mean (d0, d1) -> (0, 0) would be a projected permuation? That doesn't sound right.
I think you need a different function to check for something like prjected permutation with broadcast like a generalization of isPermutationOfMinorIdentityWithBroadcasting?