[mlir][linalg] Expand test case for tile-and-fuse with transform dialect

Reverse the order of the payload ops. fuse_into_containing_op should still work.

Differential Revision: https://reviews.llvm

[mlir][linalg] Expand test case for tile-and-fuse with transform dialect

Reverse the order of the payload ops. fuse_into_containing_op should still work.

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

show more ...

[mlir] Transform dialect: separate dependent and generated dialects

In the Transform dialect extensions, provide the separate mechanism to
declare dependent dialects (the dialects the transform IR d

[mlir] Transform dialect: separate dependent and generated dialects

In the Transform dialect extensions, provide the separate mechanism to
declare dependent dialects (the dialects the transform IR depends on)
and the generated dialects (the dialects the payload IR may be
transformed into). This allows the Transform dialect clients that are
only constructing the transform IR to avoid loading the dialects
relevant for the payload IR along with the Transform dialect itself,
thus decreasing the build/link time.

Reviewed By: springerm

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

show more ...

[mlir] Add ReplicateOp to the Transform dialect

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

[mlir] Add ReplicateOp to the Transform dialect

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

Reviewed By: nicolasvasilache

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

show more ...

[mlir][Transform] Fix isDefiniteFailure helper

This newly added helper was returning definiteFailure even in the case of silenceableFailure.

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

[mlir][Transform] Make applyToOne return a DiagnosedSilenceableFailure

This revision revisits the implementation of applyToOne and its handling
of recoverable errors as well as propagation of null h

[mlir][Transform] Make applyToOne return a DiagnosedSilenceableFailure

This revision revisits the implementation of applyToOne and its handling
of recoverable errors as well as propagation of null handles.
The implementation is simplified to always require passing a vector<Operation*>
in which the results are returned, resulting in less template instantiation magic.

Reviewed By: ftynse

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

show more ...

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[mlir][Transform] Fix implementation of the generic apply that is based on applyToOne.

The result of applying an N-result producing transformation to M payload ops
is an M-wide result, each containi

[mlir][Transform] Fix implementation of the generic apply that is based on applyToOne.

The result of applying an N-result producing transformation to M payload ops
is an M-wide result, each containing N result operations.
This requires a transposition of the results obtained by calling `applyToOne`.

This revision fixes the issue and adds more advanced tests that exercise the behavior.

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

show more ...

[mlir][Transform] NFC - Pass TransformState as an argument to applyToOne methods

This will allow implementing state-dependent behavior in the future.

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

[mlir][Transform] NFC - Pass TransformState as an argument to applyToOne methods

This will allow implementing state-dependent behavior in the future.

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

show more ...

[mlir][Linalg] Split reduction transform op

This revision separates the `LinalgSplitReduction` pattern, whose application is based on attributes,
from its implementation.
A transform dialect op exte

[mlir][Linalg] Split reduction transform op

This revision separates the `LinalgSplitReduction` pattern, whose application is based on attributes,
from its implementation.
A transform dialect op extension is added to control the application of the transformation at a finer granularity.

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

show more ...

[mlir] Don't use Optional::hasValue (NFC)

[mlir] address post-commit review for D127724

- make transform.alternatives op apply only to isolated-from-above payload IR
scopes;
- fix potential leak;
- fix several typos.

[mlir] Introduce transform.alternatives op

Introduce a transform dialect op that allows one to attempt different
transformation sequences on the same piece of payload IR until one of them
succeeds.

[mlir] Introduce transform.alternatives op

Introduce a transform dialect op that allows one to attempt different
transformation sequences on the same piece of payload IR until one of them
succeeds. This op fundamentally expands the scope of possibilities in the
transform dialect that, until now, could only propagate transformation failure,
at least using in-tree operations. This requires a more detailed specification
of the execution model for the transform dialect that now indicates how failure
is handled and propagated.

Transformations described by transform operations now have tri-state results,
with some errors being fundamentally irrecoverable (e.g., generating malformed
IR) and some others being recoverable by containing ops. Existing transform ops
directly implementing the `apply` interface method are updated to produce this
directly. Transform ops with the `TransformEachTransformOpTrait` are currently
considered to produce only irrecoverable failures and will be updated
separately.

Reviewed By: springerm

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

show more ...

[mlir] add a dynamic user-after-parent-freed transform dialect check

In the transform dialect, a transform IR handle may be pointing to a payload IR
operation that is an ancestor of another payload

[mlir] add a dynamic user-after-parent-freed transform dialect check

In the transform dialect, a transform IR handle may be pointing to a payload IR
operation that is an ancestor of another payload IR operation pointed to by
another handle. If such a "parent" handle is consumed by a transformation, this
indicates that the associated operation is likely rewritten, which in turn
means that the "child" handle may now be associated with a dangling pointer or
a pointer to a different operation than originally. Add a handle invalidation
mechanism to guard against such situations by reporting errors at runtime.

Reviewed By: springerm

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

show more ...

[mlir] Use-after-free checker for the Transform dialect

The Transform dialect uses the side effect modeling mechanism to record the
effects of the transform ops on the mapping between Transform IR v

[mlir] Use-after-free checker for the Transform dialect

The Transform dialect uses the side effect modeling mechanism to record the
effects of the transform ops on the mapping between Transform IR values and
Payload IR ops. Introduce a checker pass that warns if a Transform IR value is
used after it has been freed (consumed). This pass is mostly intended as a
debugging aid in addition to the verification/assertion mechanisms in the
transform interpreter. It reports all potential use-after-free situations.
The implementation makes a series of simplifying assumptions to be simple and
conservative. A more advanced implementation would rely on the data flow-like
analysis associated with a side-effect resource rather than a value, which is
currently not supported by the analysis infrastructure.

Reviewed By: springerm

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

show more ...

[mlir] improve and test TransformState::Extension

Add the mechanism for TransformState extensions to update the mapping between
Transform IR values and Payload IR operations held by the state. The m

[mlir] improve and test TransformState::Extension

Add the mechanism for TransformState extensions to update the mapping between
Transform IR values and Payload IR operations held by the state. The mechanism
is intentionally restrictive, similarly to how results of the transform op are
handled.

Introduce test ops that exercise a simple extension that maintains information
across the application of multiple transform ops.

Reviewed By: nicolasvasilache

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

show more ...

[mlir] use side effects in the Transform dialect

Currently, the sequence of Transform dialect operations only supports a single
use of each operand (verified by the `transform.sequence` operation).

[mlir] use side effects in the Transform dialect

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.

Reviewed By: Mogball

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

show more ...

[mlir] Connect Transform dialect to PDL

This introduces a pair of ops to the Transform dialect that connect it to PDL
patterns. Transform dialect relies on PDL for matching the Payload IR ops that
a

[mlir] Connect Transform dialect to PDL

This introduces a pair of ops to the Transform dialect that connect it to PDL
patterns. Transform dialect relies on PDL for matching the Payload IR ops that
are about to be transformed. For this purpose, it provides a container op for
patterns, a "pdl_match" op and transform interface implementations that call
into the pattern matching infrastructure.

To enable the caching of compiled patterns, this also provides the extension
mechanism for TransformState. Extensions allow one to store additional
information in the TransformState and thus communicate it between different
Transform dialect operations when they are applied. They can be added and
removed when applying transform ops. An extension containing a symbol table in
which the pattern names are resolved and a pattern compilation cache is
introduced as the first client.

Depends On D123664

Reviewed By: Mogball

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

show more ...

[mlir][transform] Introduce transform.sequence op

Sequence is an important transform combination primitive that just indicates
transform ops being applied in a row. The simplest version requires fai

[mlir][transform] Introduce transform.sequence op

Sequence is an important transform combination primitive that just indicates
transform ops being applied in a row. The simplest version requires fails
immediately if any transformation in the sequence fails. Introducing this
operation allows one to start placing transform IR within other IR.

Depends On D123135

Reviewed By: Mogball, rriddle

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

show more ...

[mlir] fix compiler warnings

-Wsign-compare and -Wunsued-value in the recently introduced code.

[mlir] Introduce Transform dialect

This dialect provides operations that can be used to control transformation of
the IR using a different portion of the IR. It refers to the IR being
transformed as

[mlir] Introduce Transform dialect

This dialect provides operations that can be used to control transformation of
the IR using a different portion of the IR. It refers to the IR being
transformed as payload IR, and to the IR guiding the transformation as
transform IR.

The main use case for this dialect is orchestrating fine-grain transformations
on individual operations or sets thereof. For example, it may involve finding
loop-like operations with specific properties (e.g., large size) in the payload
IR, applying loop tiling to those and only those operations, and then applying
loop unrolling to the inner loops produced by the previous transformations. As
such, it is not intended as a replacement for the pass infrastructure, nor for
the pattern rewriting infrastructure. In the most common case, the transform IR
will be processed and applied to payload IR by a pass. Transformations
expressed by the transform dialect may be implemented using the pattern
infrastructure or any other relevant MLIR component.

This dialect is designed to be extensible, that is, clients of this dialect are
allowed to inject additional operations into this dialect using the newly
introduced in this patch `TransformDialectExtension` mechanism. This allows the
dialect to avoid a dependency on the implementation of the transformation as
well as to avoid introducing dialect-specific transform dialects.

See https://discourse.llvm.org/t/rfc-interfaces-and-dialects-for-precise-ir-transformation-control/60927.

Reviewed By: nicolasvasilache, Mogball, rriddle

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

show more ...