Introduce a new kind of values into the transform dialect -- parameter
values. These values have a type implementing the new
TransformParamTypeInterface and are associated with lists of
attributes rather than lists of payload operations. This mechanism
allows one to wrap numeric calculations, typically heuristics, into
transform operations separate from those at actually applying the
transformation. For example, tile size computation can be now separated
from tiling itself, and not hardcoded in the transform dialect. This
further improves the separation of concerns between transform choice and
implementation.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/docs/Dialects/Transform.md | ||
---|---|---|
45–46 | Is there an equivalent to PDL_Operation? Something that could be used when we don't have a type for a certain attribute. E.g., there is no type affine_map attributes. Or is there no such "catch all" type on purpose, so that users must use proper types (and maybe add new ones for affine_map etc.) from the beginning? | |
63–64 | Maybe worth mentioning somewhere that a transform op can have multiple results and return both handles and parameters. | |
71 | Only the former one? The latter one represents attributes that are not connected to payload ops. | |
mlir/include/mlir/Dialect/Transform/IR/TransformInterfaces.h | ||
355 | why default size here but not for TransformOpMapping? | |
961 | Why do we need to model read/write/allocate/... effects for Parameters? Or does this sentence refer to handles only? | |
mlir/include/mlir/Dialect/Transform/IR/TransformTypes.td | ||
43 | Can be any $type? Why limit this to integers? Is that because we cannot easily verify that the associated attributes match the specified type in general? Should this be called Transform_IntegerParamType? Or it will this type be extended over time, e.g., add support for float to the verifier + update description? | |
47 | Should this be IntegerType? | |
mlir/lib/Dialect/Transform/IR/TransformInterfaces.cpp | ||
105–106 | Can the top-level be a param? |
Address review.
mlir/docs/Dialects/Transform.md | ||
---|---|---|
45–46 | We generally should use proper types, and introduce them when necessary. The use PDL_Operation is due to my laziness in the beginning to introduce a Transform_AnyOp type. Unlike operations, where we could indeed have a transformation that applies to any operation, I don't see a use case for a transformation parameterized by any attribute. (The only valid example I can come up with is attaching said attribute to the op, but we shouldn't be exposing such low-level details in the transform dialect). | |
mlir/include/mlir/Dialect/Transform/IR/TransformInterfaces.h | ||
961 | Handles only, indeed. | |
mlir/include/mlir/Dialect/Transform/IR/TransformTypes.td | ||
43 | Good point. I expect this to be slightly extended over time, but not to support arbitrary types. We don't have an Attribute equivalent of a memref or of !pdl.operation, that would become usable here should we remove the restriction. So this is better off as a tightly-controlled list of accepted types. A non-scalar type is also likely better of wrapped into a separate transform type. | |
47 | No, this may be extended. | |
mlir/lib/Dialect/Transform/IR/TransformInterfaces.cpp | ||
105–106 | Top-level is an alias for nullptr, we are querying the type below. Made it more clear. |
Is there an equivalent to PDL_Operation? Something that could be used when we don't have a type for a certain attribute. E.g., there is no type affine_map attributes. Or is there no such "catch all" type on purpose, so that users must use proper types (and maybe add new ones for affine_map etc.) from the beginning?