This is an archive of the discontinued LLVM Phabricator instance.

[mlir] use side effects in the Transform dialect
ClosedPublic

Authored by ftynse on Apr 21 2022, 9:15 AM.

Details

Summary

Currently, the sequence of Transform dialect operations only supports a single
use of each operand (verified by the transform.sequence operation). This was
originally motivated by the need to guard against accessing a payload IR
operation associated with a transform IR value after this operation has likely
been rewritten by a transformation. However, not all Transform dialect
operations rewrite payload IR, in particular the "navigation" operation such as
transform.pdl_match do not.

Introduce memory effects to the Transform dialect operations to describe their
effect on the payload IR and the mapping between payload IR opreations and
transform IR values. Use these effects to replace the single-use rule, allowing
repeated reads and disallowing use-after-free, where operations with the "free"
effect are considered to "consume" the transform IR value and rewrite the
corresponding payload IR operations). As an additional improvement, this
enables code motion transformation on the transform IR itself.

Diff Detail

Event Timeline

ftynse created this revision.Apr 21 2022, 9:15 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 21 2022, 9:15 AM
ftynse requested review of this revision.Apr 21 2022, 9:15 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 21 2022, 9:15 AM

Does allowing the reordering of transform operations really make sense if they do not declare all their pattern inputs and outputs? E.g.

alloc/write(%1) = transform.foo read(%0) 
alloc/write(%2) = transform.bar read(%0)

What if foo creates other ops for which bar optionally checks and which, if present, change what bar does? Reordering these two operations becomes invalid. Any transform op that corresponds to a pattern, for example, that is not purely functional (i.e. that does not declare all of its input ops and output ops) will need to be annotated with a generic MemoryRead and MemoryWrite.

mlir/include/mlir/Dialect/Transform/IR/TransformDialect.td
68
69
125
150
152

Can you add some transform IR code to go along with the explanation?

mlir/include/mlir/Dialect/Transform/IR/TransformEffects.td
39
42
mlir/include/mlir/Dialect/Transform/IR/TransformInterfaces.h
385
392
mlir/lib/Dialect/Transform/IR/TransformInterfaces.cpp
111–113
ftynse updated this revision to Diff 424400.Apr 22 2022, 1:28 AM
ftynse marked 9 inline comments as done.

Address review.

Does allowing the reordering of transform operations really make sense if they do not declare all their pattern inputs and outputs? E.g.

alloc/write(%1) = transform.foo read(%0) 
alloc/write(%2) = transform.bar read(%0)

What if foo creates other ops for which bar optionally checks and which, if present, change what bar does? Reordering these two operations becomes invalid. Any transform op that corresponds to a pattern, for example, that is not purely functional (i.e. that does not declare all of its input ops and output ops) will need to be annotated with a generic MemoryRead and MemoryWrite.

Indeed, such ops will have to be annotated with read/write on the PayloadIRResource, which is the right mechanism to disallow reordering. With time, we can use the parameter field of the EffectInstance to qualify payload IR changes at a finer grain if desired.

This does allow permuting and deduplicating read-only ops as well as repeated reads from the same handle, which sounds quite useful.

mlir/lib/Dialect/Transform/IR/TransformInterfaces.cpp
111–113

Why? I expect clear not to free the dynamically allocated memory (if any) so it can be reused on future iterations if necessary, this would be impossible with a vector freshly created in each iteration.

Mogball accepted this revision.Apr 22 2022, 9:59 AM
Mogball added inline comments.
mlir/lib/Dialect/Transform/IR/TransformInterfaces.cpp
111–113

Oh, right you are

This revision is now accepted and ready to land.Apr 22 2022, 9:59 AM
rriddle added inline comments.Apr 22 2022, 10:08 AM
mlir/lib/Dialect/Transform/IR/TransformOps.cpp
183

Missing static here?

This revision was landed with ongoing or failed builds.Apr 22 2022, 2:29 PM
This revision was automatically updated to reflect the committed changes.