Small change to support projected permutations in the
'getPermutedPosition' utility.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I am sorry but this API does not make sense to me, I think it was mistakenly added, IMO
Optional<int64_t> AffineMap::getResultPosition(AffineExpr)
makes much more sense and does not require Permutation, ProjectedPermutation, PermutationWithMaybeSomeBroadcast or other characterizations; if works with any AffineMap.
The client is responsible for assertions (it already is in this case).
Use unsigned if you really must (for maintaining consistency with neighbouring code) but we know this is not a good use case of unsigned by now and should be globally cleaned up in the future.
I'm sorry, Nicolas, I'm not sure I follow what the AffineExpr input is.
I changed the name to getResultPos and removed the assert so that it works for any case.
Please, let me know if that is not what you wanted!
The AffineExpr is what the client passes, it can be an AffineDimExpr(pos) or not.
Client-side:
assert(order.isPermutation()); auto maybePos = order.getFirstResultPosition(AffineDimExpr::get(d, ctx)); assert(maybePos.has_value()); return *maybePos;
AffineMap-side:
Optional<unsigned> AffineMap::getFirstResultPosition(AffineExpr desiredExpr) const { for (unsigned i = 0, numResults = getNumResults(); i < numResults; i++) { if (getResult(i) == desiredExpr) return i; } return llvm::None; }
Actually, now that I write it, it looks a lot like a C++ find, so findResult ?
I think that is computing something different. The input in the original utility is an input dimension position and we want to figure out what the position of that dimension is in the result (assuming a projected permutation). We don't have the result expression.
For example, for (d0, d1, d2, d3) -> (d1, d0), the input to the utility would be 0, 1, 2 or 3, and the utility would return 1, 0, None, None, respectively, for those inputs. It's kind of applying the map to an input dimension position. Does it make sense?
Yes absolutely, and taking your example, what I am suggesting is that the input to the utility would be AffineDimExpr::get(0, ctx), AffineDimExpr::get(1, ctx),AffineDimExpr::get(2, ctx),AffineDimExpr::get(3, ctx) and the utility would return 1, 0, None, None, respectively, for those inputs.
This makes the API take a generic AffineExpr input and avoid passing magic integers that get a special meaning.
This is more general and less surprising to use.
mlir/include/mlir/IR/AffineMap.h | ||
---|---|---|
169 | Please update the comment. Extracts the first result position where `input` resides. Return llvm::None if `input` cannot be found. |
Please update the comment.