This is an archive of the discontinued LLVM Phabricator instance.

[mlir] introduce parameters into the transofrm dialect
ClosedPublic

Authored by ftynse on Jan 4 2023, 6:12 AM.

Details

Summary

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.

Diff Detail

Event Timeline

ftynse created this revision.Jan 4 2023, 6:12 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 4 2023, 6:12 AM
ftynse requested review of this revision.Jan 4 2023, 6:12 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 4 2023, 6:12 AM
springerm accepted this revision.Jan 5 2023, 2:07 AM
springerm added inline comments.
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?

This revision is now accepted and ready to land.Jan 5 2023, 2:07 AM
ftynse updated this revision to Diff 486579.Jan 5 2023, 7:41 AM
ftynse marked 8 inline comments as done.

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.

This revision was automatically updated to reflect the committed changes.