This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Add ReplicateOp to the Transform dialect
ClosedPublic

Authored by ftynse on Jul 6 2022, 9:21 AM.

Details

Summary

This handle manipulation operation allows one to define a new handle that is
associated with a the same payload IR operations N times, where N can be driven
by the size of payload IR operation list associated with another handle. This
can be seen as a sort of broadcast that can be used to ensure the lists
associated with two handles have equal numbers of payload IR ops as expected by
many pairwise transform operations.

Introduce an additional "expensive" check that guards against consuming a
handle that is assocaited with the same payload IR operation more than once as
this is likely to lead to double-free or other undesired effects.

Depends On D129110

Diff Detail

Event Timeline

ftynse created this revision.Jul 6 2022, 9:21 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 6 2022, 9:21 AM
ftynse requested review of this revision.Jul 6 2022, 9:21 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 6 2022, 9:21 AM
ftynse updated this revision to Diff 442914.Jul 7 2022, 7:33 AM

Rebase.

ftynse updated this revision to Diff 443205.Jul 8 2022, 4:40 AM

Rebase.

nicolasvasilache accepted this revision.Jul 11 2022, 9:33 AM

LGTM conditioned on a more meaningful example / test (can be in a followup if too annoying now).

mlir/include/mlir/Dialect/Transform/IR/TransformOps.td
201

typo: Replicate

mlir/lib/Dialect/Transform/IR/TransformInterfaces.cpp
207

Here the key information is "consumed", can we make it stand out more ?
The linearity properties of the IR are not always trivial to make out from error messages and this error message is tricky, would be great to beef up.

371

Seems to me that consumed relates to free and not to read ?
Will it always be impossible to have free and !read ? (if so please add an assertion)

402

modifies seems unrelated to read, can you either rename the helper or split its uses further between reads and writes/modifies ?

mlir/test/Dialect/Transform/expensive-checks.mlir
57

yes, I would go overboard with the error message here as it is an exception to the linear IR we see in most place.

mlir/test/Dialect/Transform/test-interpreter.mlir
593

Any chance to have a more meaningful example in IR (either here or in the doc) ?
Would be great to link this to the example that prompted you to add this op.
As it stands right now it feels like it is useful, it is well tested in isolation but it is quite unclear how it really improves life.

This revision is now accepted and ready to land.Jul 11 2022, 9:33 AM
This revision was automatically updated to reflect the committed changes.
ftynse marked 6 inline comments as done.
ftynse added inline comments.Jul 12 2022, 2:10 AM
mlir/lib/Dialect/Transform/IR/TransformInterfaces.cpp
207

I wouldn't think about the model as global linearity with exceptions. Many transform ops consume their "main" operand handles and produce new handles because they transform the associated payload ops. They will not consume the handles pointing to options, such as tile sizes. A non-negligible amount of transform ops will not consume any of their operand handles. Without the linearity assumption, you need to pay attention to the side effects on each operand, but that makes it simpler IMO, just look at the documentation.

Added the operand number for a more helpful message, but there isn't much more that can be done here.

371

Consumed is read-and-free by convention. Just free sounds pretty much useless, it will mean the transformation drops a handle without doing anything with it.

402

It's hard for me to see how one can modify the payload IR without reading it, even if only for setting the right insertion point. The only situation where this happens is the complete replacement of the top-level payload IR operation (module), which is disallowed elsewhere, so the "write without reading" should never happen.

mlir/test/Dialect/Transform/test-interpreter.mlir
593

There are 7 follow-up patches...