We check whether the maximum index of dimensional identifier present
in the result expressions is less than dimCount (number of dimensional
identifiers) argument passed in the AffineMap::get() and the maximum index
of symbolic identifier present in the result expressions is less than
symbolCount (number of symbolic identifiers) argument passed in AffineMap::get().
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/IR/MLIRContext.cpp | ||
---|---|---|
1021–1040 | Instead of recursion, can you use a worklist? |
mlir/lib/IR/MLIRContext.cpp | ||
---|---|---|
1021–1040 | The recursion here is no different than the recursion that happens when parsing affine expressions, walking, simplifying, or processing affine expressions. Using a worklist would be harder to read. Note that this is recursing over existing IR (left and right sub-trees of binary exprs) -- it's bounded and O(IR size). Such recursion is allowed, right? |
mlir/lib/IR/MLIRContext.cpp | ||
---|---|---|
39 | I think you won't need this include. |
mlir/lib/IR/MLIRContext.cpp | ||
---|---|---|
1014 | You can write this check in 3 lines by calling AffineMap::inferFromExprList and checking against the returned AffineMap. |
ping @rriddle and @nicolasvasilache can you please take a look at the replies of your respective comments.
mlir/lib/IR/MLIRContext.cpp | ||
---|---|---|
1014 | AffineMap::inferFromExprList calls AffineMap::get() internally, which causes a layering issue as we are indirectly calling AffineMap::get() from inside AffineMap::get(). But before calling AffineMap::get() using a similar traversal. So, first creating a correct map separately, and then checking whether numDims and numSymbols follow the constraints will do an extra map allocation, as it will call the getImpl() for creating the correct map. Our aim is to not create any map at all if the arguments are wrong. |
mlir/lib/IR/MLIRContext.cpp | ||
---|---|---|
1014 | Sure, but I imagine you can think of ways of layering this differently? Absolute worst case, you can expose: template <typename AffineExprContainer> static void getMaxDimAndSymbol(ArrayRef<AffineExprContainer> exprsList, int64_t &maxDim, int64_t &maxSym) { as a util and reuse it rather than reimplement a 5 line iterative algorithm with a longer recursive one. |
@nicolasvasilache, @bondhugula and @rriddle, I have addressed all your comments. Please take a look.
mlir/include/mlir/IR/AffineMap.h | ||
---|---|---|
550 ↗ | (On Diff #389883) | Missing doc comment here - it wasn't there earlier, but we should add one now that this is publicly exposed. |
mlir/include/mlir/IR/AffineMap.h | ||
---|---|---|
549 ↗ | (On Diff #390098) | Nit: position -> positions in the `exprsLists` -> in `exprsLists` |
mlir/lib/IR/MLIRContext.cpp | ||
---|---|---|
1014 | "nodiscard" isn't universally supported and it is a c++17 extension, so someone removed it after you committed this. But more importantly: this is not desirable! What it means is to force the compiler to emit this function in the binary even if unused, there is a rarely a reason to do that, it'll just bloat the binary size. I assume that the problem is the warning about this function being unused, in this case you can:
|
I think you won't need this include.