[mlir][linalg] Expand test case for tile-and-fuse with transform dialectReverse 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 dialectReverse 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 dialectsIn the Transform dialect extensions, provide the separate mechanism todeclare dependent dialects (the dialects the transform IR d
[mlir] Transform dialect: separate dependent and generated dialectsIn the Transform dialect extensions, provide the separate mechanism todeclare dependent dialects (the dialects the transform IR depends on)and the generated dialects (the dialects the payload IR may betransformed into). This allows the Transform dialect clients that areonly constructing the transform IR to avoid loading the dialectsrelevant for the payload IR along with the Transform dialect itself,thus decreasing the build/link time.Reviewed By: springermDifferential Revision: https://reviews.llvm.org/D130289
[mlir] Use semantically readable functions for transform op effectsA recent commit introduced helper functions with semantically meaningful namesto populate the lists of memory effects in transfor
[mlir] Use semantically readable functions for transform op effectsA recent commit introduced helper functions with semantically meaningful namesto populate the lists of memory effects in transform ops, use them wheneverpossible.Depends On D129287Reviewed By: springermDifferential Revision: https://reviews.llvm.org/D129365
[mlir] Add ReplicateOp to the Transform dialectThis handle manipulation operation allows one to define a new handle that isassociated with a the same payload IR operations N times, where N can be
[mlir] Add ReplicateOp to the Transform dialectThis handle manipulation operation allows one to define a new handle that isassociated with a the same payload IR operations N times, where N can be drivenby the size of payload IR operation list associated with another handle. Thiscan be seen as a sort of broadcast that can be used to ensure the listsassociated with two handles have equal numbers of payload IR ops as expected bymany pairwise transform operations.Introduce an additional "expensive" check that guards against consuming ahandle that is assocaited with the same payload IR operation more than once asthis is likely to lead to double-free or other undesired effects.Depends On D129110Reviewed By: nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D129216
[mlir][Transform] Fix isDefiniteFailure helperThis 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 DiagnosedSilenceableFailureThis revision revisits the implementation of applyToOne and its handlingof recoverable errors as well as propagation of null h
[mlir][Transform] Make applyToOne return a DiagnosedSilenceableFailureThis revision revisits the implementation of applyToOne and its handlingof 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: ftynseDifferential Revision: https://reviews.llvm.org/D129185
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 opsis 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 opsis 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
[mlir][Transform] NFC - Pass TransformState as an argument to applyToOne methodsThis 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 methodsThis will allow implementing state-dependent behavior in the future.Differential Revision: https://reviews.llvm.org/D128327
[mlir][Linalg] Split reduction transform opThis revision separates the `LinalgSplitReduction` pattern, whose application is based on attributes,from its implementation.A transform dialect op exte
[mlir][Linalg] Split reduction transform opThis 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
[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 opIntroduce a transform dialect op that allows one to attempt differenttransformation sequences on the same piece of payload IR until one of themsucceeds.
[mlir] Introduce transform.alternatives opIntroduce a transform dialect op that allows one to attempt differenttransformation sequences on the same piece of payload IR until one of themsucceeds. This op fundamentally expands the scope of possibilities in thetransform dialect that, until now, could only propagate transformation failure,at least using in-tree operations. This requires a more detailed specificationof the execution model for the transform dialect that now indicates how failureis handled and propagated.Transformations described by transform operations now have tri-state results,with some errors being fundamentally irrecoverable (e.g., generating malformedIR) and some others being recoverable by containing ops. Existing transform opsdirectly implementing the `apply` interface method are updated to produce thisdirectly. Transform ops with the `TransformEachTransformOpTrait` are currentlyconsidered to produce only irrecoverable failures and will be updatedseparately.Reviewed By: springermDifferential Revision: https://reviews.llvm.org/D127724
[mlir] (NFC) Clean up bazel and CMake target namesAll dialect targets in bazel have been named *Dialect and all dialecttargets in CMake have been named MLIR*Dialect.
[mlir] add a dynamic user-after-parent-freed transform dialect checkIn the transform dialect, a transform IR handle may be pointing to a payload IRoperation that is an ancestor of another payload
[mlir] add a dynamic user-after-parent-freed transform dialect checkIn the transform dialect, a transform IR handle may be pointing to a payload IRoperation that is an ancestor of another payload IR operation pointed to byanother handle. If such a "parent" handle is consumed by a transformation, thisindicates that the associated operation is likely rewritten, which in turnmeans that the "child" handle may now be associated with a dangling pointer ora pointer to a different operation than originally. Add a handle invalidationmechanism to guard against such situations by reporting errors at runtime.Reviewed By: springermDifferential Revision: https://reviews.llvm.org/D127480
[mlir] Use-after-free checker for the Transform dialectThe Transform dialect uses the side effect modeling mechanism to record theeffects of the transform ops on the mapping between Transform IR v
[mlir] Use-after-free checker for the Transform dialectThe Transform dialect uses the side effect modeling mechanism to record theeffects of the transform ops on the mapping between Transform IR values andPayload IR ops. Introduce a checker pass that warns if a Transform IR value isused after it has been freed (consumed). This pass is mostly intended as adebugging aid in addition to the verification/assertion mechanisms in thetransform interpreter. It reports all potential use-after-free situations.The implementation makes a series of simplifying assumptions to be simple andconservative. A more advanced implementation would rely on the data flow-likeanalysis associated with a side-effect resource rather than a value, which iscurrently not supported by the analysis infrastructure.Reviewed By: springermDifferential Revision: https://reviews.llvm.org/D126381
[mlir] improve and test TransformState::ExtensionAdd the mechanism for TransformState extensions to update the mapping betweenTransform IR values and Payload IR operations held by the state. The m
[mlir] improve and test TransformState::ExtensionAdd the mechanism for TransformState extensions to update the mapping betweenTransform IR values and Payload IR operations held by the state. The mechanismis intentionally restrictive, similarly to how results of the transform op arehandled.Introduce test ops that exercise a simple extension that maintains informationacross the application of multiple transform ops.Reviewed By: nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D124778
[mlir] use side effects in the Transform dialectCurrently, the sequence of Transform dialect operations only supports a singleuse of each operand (verified by the `transform.sequence` operation).
[mlir] use side effects in the Transform dialectCurrently, the sequence of Transform dialect operations only supports a singleuse of each operand (verified by the `transform.sequence` operation). This wasoriginally motivated by the need to guard against accessing a payload IRoperation associated with a transform IR value after this operation has likelybeen rewritten by a transformation. However, not all Transform dialectoperations 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 theireffect on the payload IR and the mapping between payload IR opreations andtransform IR values. Use these effects to replace the single-use rule, allowingrepeated reads and disallowing use-after-free, where operations with the "free"effect are considered to "consume" the transform IR value and rewrite thecorresponding payload IR operations). As an additional improvement, thisenables code motion transformation on the transform IR itself.Reviewed By: MogballDifferential Revision: https://reviews.llvm.org/D124181
[mlir] Connect Transform dialect to PDLThis introduces a pair of ops to the Transform dialect that connect it to PDLpatterns. Transform dialect relies on PDL for matching the Payload IR ops thata
[mlir] Connect Transform dialect to PDLThis introduces a pair of ops to the Transform dialect that connect it to PDLpatterns. Transform dialect relies on PDL for matching the Payload IR ops thatare about to be transformed. For this purpose, it provides a container op forpatterns, a "pdl_match" op and transform interface implementations that callinto the pattern matching infrastructure.To enable the caching of compiled patterns, this also provides the extensionmechanism for TransformState. Extensions allow one to store additionalinformation in the TransformState and thus communicate it between differentTransform dialect operations when they are applied. They can be added andremoved when applying transform ops. An extension containing a symbol table inwhich the pattern names are resolved and a pattern compilation cache isintroduced as the first client.Depends On D123664Reviewed By: MogballDifferential Revision: https://reviews.llvm.org/D124007
[mlir][transform] Introduce transform.sequence opSequence is an important transform combination primitive that just indicatestransform ops being applied in a row. The simplest version requires fai
[mlir][transform] Introduce transform.sequence opSequence is an important transform combination primitive that just indicatestransform ops being applied in a row. The simplest version requires failsimmediately if any transformation in the sequence fails. Introducing thisoperation allows one to start placing transform IR within other IR.Depends On D123135Reviewed By: Mogball, rriddleDifferential Revision: https://reviews.llvm.org/D123664
[mlir] fix compiler warnings-Wsign-compare and -Wunsued-value in the recently introduced code.
[mlir] Introduce Transform dialectThis dialect provides operations that can be used to control transformation ofthe IR using a different portion of the IR. It refers to the IR beingtransformed as
[mlir] Introduce Transform dialectThis dialect provides operations that can be used to control transformation ofthe IR using a different portion of the IR. It refers to the IR beingtransformed as payload IR, and to the IR guiding the transformation astransform IR.The main use case for this dialect is orchestrating fine-grain transformationson individual operations or sets thereof. For example, it may involve findingloop-like operations with specific properties (e.g., large size) in the payloadIR, applying loop tiling to those and only those operations, and then applyingloop unrolling to the inner loops produced by the previous transformations. Assuch, it is not intended as a replacement for the pass infrastructure, nor forthe pattern rewriting infrastructure. In the most common case, the transform IRwill be processed and applied to payload IR by a pass. Transformationsexpressed by the transform dialect may be implemented using the patterninfrastructure or any other relevant MLIR component.This dialect is designed to be extensible, that is, clients of this dialect areallowed to inject additional operations into this dialect using the newlyintroduced in this patch `TransformDialectExtension` mechanism. This allows thedialect to avoid a dependency on the implementation of the transformation aswell 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, rriddleDifferential Revision: https://reviews.llvm.org/D123135