Depends on: D144717
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgTransformOps.td | ||
---|---|---|
771–772 | Does this also compute an upper bound for tensor dimensions? What happens if the low/high padding and/or tensor source depends on the loop IV? | |
780 | result | |
791 | A loop handle may compose better with the remaining transform dialect ops. |
mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgTransformOps.td | ||
---|---|---|
772 | Nit: please describe the format of the transform attrbute. | |
780 | I see this text is being copy-pasted, but the logic of apply-to-each doesn't just drop uncompatible ops, it emits a silenceable failure. | |
781 | Nit: it's not a PDLOperation. | |
793 | We don't want overconstrained result types to avoid proliferation of casts, see doc |
mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgTransformOps.td | ||
---|---|---|
771–772 | Does this also compute an upper bound for tensor dimensions? It does and that has been around for a while; we want to evolve that and merge with your WIP PR that goes towards generalization. | |
791 | Maybe, OTOH getting explicit handles is more cumbersome and makes it harder to e.g. devise tuning scripts. | |
793 | thanks! |
mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h | ||
---|---|---|
414 | Nit: If we don't want to give any special meaning to negative numLoops (e.g., -1 means all of them) maybe we should use unsigned. Note: I realize that numLoops is used in different APIs with the same type so we can do this clean-up in a separate PR. |
mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgTransformOps.td | ||
---|---|---|
771 | Nit: "given number of loops" => "at most the given number of loops"? We may even want to add wording that the actual number depends on the number of enclosing loops and the given number of loops, whichever is the smallest. It wasn't clear to me what would happen if we give a number of loops greater than the actual number of enclosing loops. I had to look at the implementation to check. |
mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h | ||
---|---|---|
414 | Moved to int64_t. I am generally wary of using unsigned to represent non-negative.. unsigned should only be used in very specific limited cases in C++ (e.g. bit manipulation and overflow behavior). |
mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h | ||
---|---|---|
414 | Yeah, it has some unfortunate codegen implications. Ideally we would want something that carries the semantic that this number is never negative, while not generating a bunch of codegen/perf overhead. |
Nit: "given number of loops" => "at most the given number of loops"?
We may even want to add wording that the actual number depends on the number of enclosing loops and the given number of loops, whichever is the smallest.
It wasn't clear to me what would happen if we give a number of loops greater than the actual number of enclosing loops. I had to look at the implementation to check.