This commit adds automatic unpacking of Value's of type pdl::OperationType to the underlying single-result OpResult.
This allows mixing single-value, attribute and multi-value pdl::Operation tile sizes and num threads to TileToForeachThreadOp.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgTransformOps.td | ||
---|---|---|
799 | to | |
799–800 | I would rephrase this: `tile_sizes` and `num_threads` are variadic. Each tile size/number of threads can be an index attribute or a transform handle that is mapped to exactly one payload op with exactly one index result. | |
mlir/lib/Dialect/Linalg/TransformOps/LinalgTransformOps.cpp | ||
1330–1333 | Why do you change this? The name of the attr in the .td file is mapping. | |
1360 | May need updating | |
1418 | May need updating | |
1436 | rename variable | |
1438 | No loop needed, because the must be exactly one payload op. Raise an error if a different number of payload ops are mapped. | |
1483–1484 | Nit: If you add this, you skip the error checking inside of unpackPDLOperations which could be useful for debugging faulty IR. | |
1546–1551 | Why is this needed? Is this something that we should do with every transform op? |
mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgTransformOps.td | ||
---|---|---|
799–800 | thanks! | |
mlir/lib/Dialect/Linalg/TransformOps/LinalgTransformOps.cpp | ||
1360 | I switched back to mapping everywhere, is that the updating you meant or something else ? | |
1438 | No, that is the whole point of the PR, the handle may point to multiple payload ops that we need to unpack. [0, %three_tile_sizes, %c42] will unpack to 5 tiles sizes total. | |
1483–1484 | Propagating the empty state properly through the whole transform IR is much more important as it can lead to hard to track issues when used at scale. If this could be systematized, this would be great but also not on my short-term priority list. | |
1546–1551 | Yes, we should always set the expected handles in the success and silenceable failure cases otherwise hard to track bugs ensue (at the very least in the "Suppress" mode). A systematic mechanism would be very useful but not on my short term list |
to