This is an archive of the discontinued LLVM Phabricator instance.

[mlir] add support for transform dialect value handles
ClosedPublic

Authored by ftynse on Feb 6 2023, 4:33 AM.

Details

Summary

Introduce support for the third kind of values in the transform dialect:
value handles. Similarly to operation handles, value handles are
pointing to a set of values in the payload IR. This enables
transformation to be targeted at specific values, such as individual
results of a multi-result payload operation without indirecting through
the producing op or block arguments that previously could not be easily
addressed. This is expected to support a broad class of memory-oriented
transformations such as selective bufferization, buffer assignment, and
memory transfer management.

Value handles are functionally similar to operation handles and require
similar implementation logic. The most important change concerns the
handle invalidation mechanism where operation and value handles can
affect each other.

This patch includes two cleanups that make it easier to introduce value
handles:

  • RaggedArray structure that encapsulates the SmallVector of ArrayRef backed by flat SmallVector logic, frequently used in the transform interfaces implementation;
  • rewrite the tests that associated payload handles with an integer value reinterpret_casted as a pointer, which were a frequent source of confusion and crashes when adding more debugging facilities that can inspect the payload.

Diff Detail

Event Timeline

ftynse created this revision.Feb 6 2023, 4:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 6 2023, 4:33 AM
ftynse requested review of this revision.Feb 6 2023, 4:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 6 2023, 4:33 AM
ftynse updated this revision to Diff 495084.Feb 6 2023, 4:37 AM

Remove spurious commented-out code.

springerm accepted this revision.Feb 9 2023, 1:14 AM
springerm added inline comments.
mlir/docs/Dialects/Transform.md
48

Is this a new op introduced by this change? Is there also a transform.get_defining_op?

Is there a best practice when adding designing transforms ops: Is it better to return OpResults, operations or both?

mlir/include/mlir/Dialect/Transform/IR/TransformInterfaces.td
158–160

Op handle interfaces are used to support types such operation<"scf.if">, right? What's the benefit of the value handle interface? (As opposed to a single value handle type.)

This revision is now accepted and ready to land.Feb 9 2023, 1:14 AM
ftynse marked 2 inline comments as done.Feb 9 2023, 4:09 AM
ftynse added inline comments.
mlir/docs/Dialects/Transform.md
48

This is a fake op used for an example, so are all the other ops in this snippet. We may end up having such a transform, but I rather expect us to match specific values directly rather than extract them from operations.

Whether a transformation returns a result or an entire operation depends on the kind of the transformation. Data transformations will return (and likely accept) value handles.

mlir/include/mlir/Dialect/Transform/IR/TransformInterfaces.td
158–160

So we can do typed_value<i32> or value<shaped>, for example.

This revision was automatically updated to reflect the committed changes.
ftynse marked 2 inline comments as done.