[MLIR][Transform] Allow stateInitializer and stateExporter for applyTransforms (#101186)

This is discussed in RFC:

https://discourse.llvm.org/t/rfc-making-the-constructor-of-the-transformstate-cl

[MLIR][Transform] Allow stateInitializer and stateExporter for applyTransforms (#101186)

This is discussed in RFC:

https://discourse.llvm.org/t/rfc-making-the-constructor-of-the-transformstate-class-protected/80377

show more ...

[mlir] move MatchOpInterface under Transform/Interfaces (#86899)

This is similar to the TransformOpInterface move.

[mlir] split transform interfaces into a separate library (#85221)

Transform interfaces are implemented, direction or via extensions, in
libraries belonging to multiple other dialects. Those dialec

[mlir] split transform interfaces into a separate library (#85221)

Transform interfaces are implemented, direction or via extensions, in
libraries belonging to multiple other dialects. Those dialects don't
need to depend on the non-interface part of the transform dialect, which
includes the growing number of ops and transitive dependency footprint.

Split out the interfaces into a separate library. This in turn requires
flipping the dependency from the interface on the dialect that has crept
in because both co-existed in one library. The interface shouldn't
depend on the transform dialect either.

As a consequence of splitting, the capability of the interpreter to
automatically walk the payload IR to identify payload ops of a certain
kind based on the type used for the entry point symbol argument is
disabled. This is a good move by itself as it simplifies the interpreter
logic. This functionality can be trivially replaced by a
`transform.structured.match` operation.

show more ...

[mlir][transform] Add an op for replacing values with function calls (#78398)

Adds `transform.func.cast_and_call` that takes a set of inputs and
outputs and replaces the uses of those outputs with

[mlir][transform] Add an op for replacing values with function calls (#78398)

Adds `transform.func.cast_and_call` that takes a set of inputs and
outputs and replaces the uses of those outputs with a call to a function
at a specified insertion point.

The idea with this operation is to allow users to author independent IR
outside of a to-be-compiled module, and then match and replace a slice
of the program with a call to the external function.

Additionally adds a mechanism for populating a type converter with a set
of conversion materialization functions that allow insertion of
casts on the inputs/outputs to and from the types of the function
signature.

show more ...

[mlir] introduce debug transform dialect extension (#77595)

Introduce a new extension for simple print-debugging of the transform
dialect scripts. The initial version of this extension consists of

[mlir] introduce debug transform dialect extension (#77595)

Introduce a new extension for simple print-debugging of the transform
dialect scripts. The initial version of this extension consists of two
ops that are printing the payload objects associated with transform
dialect values. Similar ops were already available in the test extenion
and several downstream projects, and were extensively used for testing.

show more ...

[mlir] introduce transform.num_associations (#76723)

Add a new transform operation that creates a new parameter containing the number of payload objects (operations, values or attributes) associated

[mlir] introduce transform.num_associations (#76723)

Add a new transform operation that creates a new parameter containing the number of payload objects (operations, values or attributes) associated with the argument. This is useful in matching and for debugging purposes. This replaces three ad-hoc operations previously provided by the test extension.

show more ...

[mlir][transform] Add apply_conversion_patterns op

This transform op applies a dialect conversion to the targeted ops. Its design is similar to `apply_patterns`.

Patterns are specified in the first

[mlir][transform] Add apply_conversion_patterns op

This transform op applies a dialect conversion to the targeted ops. Its design is similar to `apply_patterns`.

Patterns are specified in the first region of `apply_conversion_patterns`. They must implement the `ConversionPatternDescriptorOpInterface`. Regular rewrite patterns and dialect conversion patterns should not be mixed, so the interface is separate from the `PatternDescriptorOpInterface`.

The type converter is specified as the single op of the second region. It is optional; if no type converter is specified, it is expected that pattern descriptors provide their own type converters. If both the pattern descriptors and the `apply_conversion_patterns` op specify a type converter, the type converter of the pattern descriptor is used.

Differential Revision: https://reviews.llvm.org/D157109

show more ...

[mlir][transform] Add VerifyOp

This transform op runs the verifier on the targeted payload ops. It is for debugging only.

Differential Revision: https://reviews.llvm.org/D154711

[mlir] integration tests for transform dialect matchers

Add integration tests exercising transform dialect matchers for slightly
larger compositions of structured ops, namely reductions and matrix
m

[mlir] integration tests for transform dialect matchers

Add integration tests exercising transform dialect matchers for slightly
larger compositions of structured ops, namely reductions and matrix
multiplications with optional leading and trailing elementwise
operations.

Reviewed By: qcolombet

Differential Revision: https://reviews.llvm.org/D154440

show more ...

[mlir][transform] Add notifyPayloadOperationReplaced to TransformRewriter

This function allows users to update payload op mappings in cases where such replacements cannot be performed automatically

[mlir][transform] Add notifyPayloadOperationReplaced to TransformRewriter

This function allows users to update payload op mappings in cases where such replacements cannot be performed automatically by the rewriter/listener interface.

Differential Revision: https://reviews.llvm.org/D153764

show more ...

[mlir][transform] fix handle invalidation check for reentrant regions

When exiting the scope of a region attached to a transform op, clean up
the handle invalidation checks assocaited with handles d

[mlir][transform] fix handle invalidation check for reentrant regions

When exiting the scope of a region attached to a transform op, clean up
the handle invalidation checks assocaited with handles defined in this
region. Otherwise, these checks may trigger on the next entry to the
region while there is no incorrect usage.

Reviewed By: springerm

Differential Revision: https://reviews.llvm.org/D153545

show more ...

[mlir][Transform] Allow parameter and value types in merge_handles op

Similar to operation handles, merging handles for other types can be useful to
avoid repetition of common transformations across

[mlir][Transform] Allow parameter and value types in merge_handles op

Similar to operation handles, merging handles for other types can be useful to
avoid repetition of common transformations across a set of parameters.
For example, forming a list of static values for comparison rather than
comparing the parameters one at a time.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D153240

show more ...

[mlir][transform] Add TransformRewriter

All `apply` functions now have a `TransformRewriter &` parameter. This rewriter should be used to modify the IR. It has a `TrackingListener` attached and upda

[mlir][transform] Add TransformRewriter

All `apply` functions now have a `TransformRewriter &` parameter. This rewriter should be used to modify the IR. It has a `TrackingListener` attached and updates the internal handle-payload mappings based on rewrites.

Implementations no longer need to create their own `TrackingListener` and `IRRewriter`. Error checking is integrated into `applyTransform`. Tracking listener errors are reported only for ops with the `ReportTrackingListenerFailuresOpTrait` trait attached, allowing for a gradual migration. Furthermore, errors can be silenced with an op attribute.

Additional API will be added to `TransformRewriter` in subsequent revisions. This revision just adds an "empty" `TransformRewriter` class and updates all `apply` implementations.

Differential Revision: https://reviews.llvm.org/D152427

show more ...

[mlir][transform] add a check for nested consumption in ApplyEachOpTrait

ApplyEachOpTrait applies to payload ops associated with its operand
handle one-by-one in order. If a handle is consumed, this

[mlir][transform] add a check for nested consumption in ApplyEachOpTrait

ApplyEachOpTrait applies to payload ops associated with its operand
handle one-by-one in order. If a handle is consumed, this usually
indicates that the associated payload ops are erased or rewritten. Add a
check that we don't consume an ancestor payload operation before
consuming its descendant, as the latter is likely to be a dangling
pointer. Transform operations for which this is a legitimate behavior
(i.e., they consume the handle but don't actually erase or rewrite the
payload operation) should implement the interface directly and allow for
repeated handles.

Reviewed By: springerm

Differential Revision: https://reviews.llvm.org/D152510

show more ...

[mlir][transform] Simplify TrackingListener test case

Use the default TrackingListener. No need to set up a derived listener just for the test case. This revision is in preparation of a future chang

[mlir][transform] Simplify TrackingListener test case

Use the default TrackingListener. No need to set up a derived listener just for the test case. This revision is in preparation of a future change that adds a TrackingRewriter infrastructure.

Differential Revision: https://reviews.llvm.org/D152446

show more ...

[mlir][transform] Add region to ApplyPatternsOp

Patterns should be selected by adding ops that implement `PatternDescriptorOpInterface` to the region of `apply_pattern` ops. Such ops can have operan

[mlir][transform] Add region to ApplyPatternsOp

Patterns should be selected by adding ops that implement `PatternDescriptorOpInterface` to the region of `apply_pattern` ops. Such ops can have operands, allowing for pattern parameterization. The existing way of selecting patterns from the PatternRegistry is deprecated.

Differential Revision: https://reviews.llvm.org/D152167

show more ...

[mlir] harden expensive-checks mode against ops with repeated operands

Transform operations may indicate that they may accept and consume
several handles pointing to the same or nested payload entit

[mlir] harden expensive-checks mode against ops with repeated operands

Transform operations may indicate that they may accept and consume
several handles pointing to the same or nested payload entities. The
initial implementation of the expensive-checks mode was simply ignoring
such cases as consuming the second handle would fail the check after the
first handle invalidated it by consuming the same payload. Additional
checks had been added since then, which could now trigger assertions in
the expensive-checks module itself (instead of or in addition to
use-after-free assertions down the road), specifically because the
payload associations for invalidated handles is removed from the state
to enable other kinds of checking.

Rework the handling of transform operations with repeated handles so
use-after-consume is still reported properly if the consumption happened
by a preceding operation, as opposed to the a preceding operand of the
same operation that is still (corretly) ignored if the op requests that.

Depends on: D151560

Reviewed By: springerm

Differential Revision: https://reviews.llvm.org/D151569

show more ...

[mlir] teach expensive-checks transform mode about empty handle

The transform dialect interpreter features the expensive-checks mode
that acts as an embedded sanitizer to track use-after-consume of

[mlir] teach expensive-checks transform mode about empty handle

The transform dialect interpreter features the expensive-checks mode
that acts as an embedded sanitizer to track use-after-consume of
transform handles. Its logic is based on the relations between payload
operations, which made it silently ignore empty handles that are
consumed. Also catch and report this case because the remaining code may
hit an assertion on attempting to access a consumed handle (that is
removed from the mapping).

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D151560

show more ...

[mlir] don't hardcode PDL_Operation in TestTransformDialectExtensions

Update operations in Transform dialect extensions used for testing to
use the more generic `TransformHandleTypeInterface` type c

[mlir] don't hardcode PDL_Operation in TestTransformDialectExtensions

Update operations in Transform dialect extensions used for testing to
use the more generic `TransformHandleTypeInterface` type constraint
instead of hardcoding `PDL_Operation`. See
https://discourse.llvm.org/t/rfc-type-system-for-the-transform-dialect/65702
for motivation. This is particularly important as these tests are often
used as source of best practices.

Update tests to use `!transform.any_op` instead of `!pdl.operation`.

Depends On D150785

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D150786

show more ...

[mlir] update types in remaining Linalg TransformOps test

All ops now support explicit type specification, update types to use
`!transform.any_op` instead of `!pdl.operation` for consistency.

Depen

[mlir] update types in remaining Linalg TransformOps test

All ops now support explicit type specification, update types to use
`!transform.any_op` instead of `!pdl.operation` for consistency.

Depends On D144515

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D150592

show more ...

[mlir][transform] Use TrackingListener-aware iterator for getPayloadOps

Instead of returning an `ArrayRef<Operation *>`, return at iterator that skips ops that were erased/replaced while iterating o

[mlir][transform] Use TrackingListener-aware iterator for getPayloadOps

Instead of returning an `ArrayRef<Operation *>`, return at iterator that skips ops that were erased/replaced while iterating over the payload ops.

This fixes an issue in conjuction with TrackingListener, where a tracked op was erased during the iteration. Elements may not be removed from an array while iterating over it; this invalidates the iterator.

When ops are erased/removed via `replacePayloadOp`, they are not immediately removed from the mappings data structure. Instead, they are set to `nullptr`. `nullptr`s are not enumerated by `getPayloadOps`. At the end of each transformation, `nullptr`s are removed from the mapping data structure.

Differential Revision: https://reviews.llvm.org/D149847

show more ...

[mlir] add structured (Linalg) transform op matchers

Add a set of transform operations into the "structured" extension of the
Transform dialect that allow one to select transformation targets more
s

[mlir] add structured (Linalg) transform op matchers

Add a set of transform operations into the "structured" extension of the
Transform dialect that allow one to select transformation targets more
specifically than the currently available matching. In particular, add
the mechanism for identifying the producers of operands (input and init
in destination-passing style) and users of results, as well as
mechanisms for reasoning about the shape of the iteration space.

Additionally, add several transform operations to manipulate parameters
that could be useful to implement more advanced selectors. Specifically,
new operations let one produce and compare parameter values to implement
shape-driven transformations.

New operations are placed in separate files to decrease compilation
time. Some relayering of the extension is necessary to avoid repeated
generation of enums.

Depends on D148013
Depends on D148014
Depends on D148015

Reviewed By: chelini

Differential Revision: https://reviews.llvm.org/D148017

show more ...

[mlir] Add transform.foreach_match

Add a new transform op combinator that implements an "if-then-else"
style of mechanism for applying transformations. Its main purpose is to
serve as a higher-level

[mlir] Add transform.foreach_match

Add a new transform op combinator that implements an "if-then-else"
style of mechanism for applying transformations. Its main purpose is to
serve as a higher-level driver when applying multiple transform scripts
to potentially overlapping pieces of the payload IR. This is similar to
how the various rewrite drivers operate in C++, but at a higher level
and with more declarative expressions. This is not intended to replace
existing pattern-based rewrites, but to to drive more complex
transformations that are exposed in the transform dialect and are too
complex to be expressed as simple declarative rewrites.

Reviewed By: springerm

Differential Revision: https://reviews.llvm.org/D148013

show more ...

[mlir][transform] Better debugging facilites for invalid API usage

This revision adds additional "expensive-checks" checks to the transform dialect that detect the most common cases of:

* Missing `

[mlir][transform] Better debugging facilites for invalid API usage

This revision adds additional "expensive-checks" checks to the transform dialect that detect the most common cases of:

* Missing `consumesHandle` side effects on transform ops.
* Patterns that remove operations but do not notify the transform dialect.

In essence, these additional checks are looking for dangling pointers to erased payload ops in the transform dialect state and crash the program execution (by dereferencing free'd memory) or triggering an assertion failure. It is recommended to run these extra checks with ASAN. Otherwise, certain failures may not be detected. The ASAN error message can also be used to find the faulty transform op/pattern.

This change also fixes a few faulty transform ops.

Differential Revision: https://reviews.llvm.org/D147447

show more ...

[mlir] reallow null results in TransformEachOpTrait

Previous changes in 98acd7468307b6099e7deae206a749af324ff95f were overly
eager to disallow null payload everywhere. The semantics of
TransformEach

[mlir] reallow null results in TransformEachOpTrait

Previous changes in 98acd7468307b6099e7deae206a749af324ff95f were overly
eager to disallow null payload everywhere. The semantics of
TransformEachOpTrait allows individual applications to return null
payloads as means of filtering out the operations to which they are not
applicable without emitting even a silenceable failure. This is a
questionable choice, but one apparently relied upon. Null payloads are
not supposed to leak outside of the trait.

Reviewed By: qcolombet

Differential Revision: https://reviews.llvm.org/D143904

show more ...