[mlir][transform] Add ForeachOp to transform dialectThis op "unbatches" an op handle and executes the loop body for each payload op.Differential Revision: https://reviews.llvm.org/D130257
[mlir][linalg][NFC] Cleanup: Drop linalg.inplaceable attributebufferization.writable is used in most cases instead. All remaining test cases are updated. Some code that is no longer needed is delet
[mlir][linalg][NFC] Cleanup: Drop linalg.inplaceable attributebufferization.writable is used in most cases instead. All remaining test cases are updated. Some code that is no longer needed is deleted.Differential Revision: https://reviews.llvm.org/D129739
show more ...
[mlir] Allow Tile transform op to take dynamic sizesExtend the definition of the Tile structured transform op to enable itaccepting handles to operations that produce tile sizes at runtime. This i
[mlir] Allow Tile transform op to take dynamic sizesExtend the definition of the Tile structured transform op to enable itaccepting handles to operations that produce tile sizes at runtime. This isuseful by itself and prepares for more advanced tiling strategies. Note thatthe changes are relevant only to the transform dialect, the tilingtransformation itself already supports dynamic sizes.Depends On D129216Reviewed By: nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D129217
[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
[mlir] Transform dialect: introduce merge_handles opThis Transform dialect op allows one to merge the lists of Payload IRoperations pointed to by several handles into a single list associated with
[mlir] Transform dialect: introduce merge_handles opThis Transform dialect op allows one to merge the lists of Payload IRoperations pointed to by several handles into a single list associated with onehandle. This is an important Transform dialect usability improvement for caseswhere transformations may temporarily diverge for different groups of PayloadIR ops before converging back to the same script. Without this op, severalcopies of the trailing transformations would have to be present in thetransformation script.Depends On D129090Reviewed By: nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D129110
[mlir][Transform] Fix applyToOne corner case when no op is matched.Such situations manifest themselves with an empty payload which ends up producing empty results.In such cases, we still want to m
[mlir][Transform] Fix applyToOne corner case when no op is matched.Such situations manifest themselves with an empty payload which ends up producing empty results.In such cases, we still want to match the transform op contract and return as many empty SmallVector<Operation*>as the op requires.Differential Revision: https://reviews.llvm.org/D128456
[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][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] 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] 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] add VectorizeOp to structured transform opsVectorization is a key transformation to achieve high performance on mostarchitectures. In the transform dialect, vectorization is implemented as
[mlir] add VectorizeOp to structured transform opsVectorization is a key transformation to achieve high performance on mostarchitectures. In the transform dialect, vectorization is implemented as aparameterizable transform op. It currently applies to a scope of payload IRdelimited by some isolated-from-above op, mainly because several enablingtransformations (such as affine simplification) are needed to performvectorization and these transformation would apply to ops other than the "main"computational payload op. A separate "navigation" transform op that obtains theisolated-from-above ancestor of an op is introduced in the core transformdialect. Even though it is currently only useful for vectorization,isolated-from-above ops are a common anchor for transformations (usuallyimplemented as passes) that is likely to be reused in the future.Depends On D126374Reviewed By: nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D126542
[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] 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