[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
Use any_of (NFC)
[mlir] Use has_value instead of hasValue (NFC)
[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
show more ...
[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] Delete ForwardDataFlowAnalysisWith SCCP and integer range analysis ported to the new framework, this old framework is redundant. Delete it.Depends on D128866Reviewed By: rriddleDiffere
[mlir] Delete ForwardDataFlowAnalysisWith SCCP and integer range analysis ported to the new framework, this old framework is redundant. Delete it.Depends on D128866Reviewed By: rriddleDifferential Revision: https://reviews.llvm.org/D128867
[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
Revert "Don't use Optional::hasValue (NFC)"This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
Don't use Optional::hasValue (NFC)
[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] fix compiler error due to commit landing race
[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] Support getSuccessorInputs from parent opOps that implement `RegionBranchOpInterface` are allowed to indicate that they can branch back to themselves in `getSuccessorRegions`, but there is n
[mlir] Support getSuccessorInputs from parent opOps that implement `RegionBranchOpInterface` are allowed to indicate that they can branch back to themselves in `getSuccessorRegions`, but there is no API that allows them to specify the forwarded operands. This patch enables that by changing `getSuccessorEntryOperands` to accept `None`.Fixes #54928Reviewed By: rriddleDifferential Revision: https://reviews.llvm.org/D127239
[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] Introduce Transform ops for loopsIntroduce transform ops for "for" loops, in particular for peeling, softwarepipelining and unrolling, along with a couple of "IR navigation" ops. These ops
[mlir] Introduce Transform ops for loopsIntroduce transform ops for "for" loops, in particular for peeling, softwarepipelining and unrolling, along with a couple of "IR navigation" ops. These opsare intended to be generalized to different kinds of loops when possible andtherefore use the "loop" prefix. They currently live in the SCF dialect asthere is no clear place to put transform ops that may span across severaldialects, this decision is postponed until the ops actually need to handlenon-SCF loops.Additionally refactor some common utilities for transform ops into trait orinterface methods, and change the loop pipelining to be a returning pattern.Reviewed By: springermDifferential Revision: https://reviews.llvm.org/D127300
[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][NFC] Shift a bunch of dialect includes from the .h to the .cppNow that dialect constructors are generated in the .cpp file, we candrop all of the dependent dialect includes from the .h file
[mlir][NFC] Shift a bunch of dialect includes from the .h to the .cppNow that dialect constructors are generated in the .cpp file, we candrop all of the dependent dialect includes from the .h file.Differential Revision: https://reviews.llvm.org/D124298
[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