Changes in pdl-bytecode.mlir

8ec28af8eaff5acd0df3e53340159c034f08533d - Reapply "[mlir][PDL] Add support for native constraints with results (#82760)"

Fri, 01 Mar 2024 22:32:27 +0000

Reapply "[mlir][PDL] Add support for native constraints with results (#82760)"with a small stack-use-after-scope fix in getConstraintPredicates()This reverts commit c80e6edba4a9593f0587e27fa0ac825ebe174afd. List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

c80e6edba4a9593f0587e27fa0ac825ebe174afd - Revert "[mlir][PDL] Add support for native constraints with results (#82760)"

Fri, 01 Mar 2024 06:44:30 +0000

Revert "[mlir][PDL] Add support for native constraints with results (#82760)"Due to buildbot failure https://lab.llvm.org/buildbot/#/builders/88/builds/72130This reverts commit dca32a3b594b3c91f9766a9312b5d82534910fa1. List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

dca32a3b594b3c91f9766a9312b5d82534910fa1 - [mlir][PDL] Add support for native constraints with results (#82760)

Fri, 01 Mar 2024 06:29:49 +0000

[mlir][PDL] Add support for native constraints with results (#82760)From https://reviews.llvm.org/D153245 This adds support for native PDL (and PDLL) C++ constraints to return results. This is useful for situations where a pattern checks for certain constraints of multiple interdependent attributes and computes a new attribute value based on them. Currently, for such an example it is required to escape to C++ during matching to perform the check and after a successful match again escape to native C++ to perform the computation during the rewriting part of the pattern. With this work we can do the computation in C++ during matching and use the result in the rewriting part of the pattern. Effectively this enables a choice in the trade-off of memory consumption during matching vs recomputation of values. This is an example of a situation where this is useful: We have two operations with certain attributes that have interdependent constraints. For instance `attr_foo: one_of [0, 2, 4, 8], attr_bar: one_of [0, 2, 4, 8]` and `attr_foo == attr_bar`. The pattern should only match if all conditions are true. The new operation should be created with a new attribute which is computed from the two matched attributes e.g. `attr_baz = attr_foo * attr_bar`. For the check we already escape to native C++ and have all values at hand so it makes sense to directly compute the new attribute value as well: ``` Constraint checkAndCompute(attr0: Attr, attr1: Attr) -> Attr; Pattern example with benefit(1) { let foo = op() {attr = attr_foo : Attr}; let bar = op(foo) {attr = attr_bar : Attr}; let attr_baz = checkAndCompute(attr_foo, attr_bar); rewrite bar with { let baz = op {attr=attr_baz}; replace bar with baz; }; } ``` To achieve this the following notable changes were necessary: PDLL: - Remove check in PDLL parser that prevented native constraints from returning results PDL: - Change PDL definition of pdl.apply_native_constraint to allow variadic results PDL_interp: - Change PDL_interp definition of pdl_interp.apply_constraint to allow variadic results PDLToPDLInterp Pass: The input to the pass is an arbitrary number of PDL patterns. The pass collects the predicates that are required to match all of the pdl patterns and establishes an ordering that allows creation of a single efficient matcher function to match all of them. Values that are matched and possibly used in the rewriting part of a pattern are represented as positions. This allows fusion and thus reusing a single position for multiple matching patterns. Accordingly, we introduce ConstraintPosition, which records the type and index of the result of the constraint. The problem is for the corresponding value to be used in the rewriting part of a pattern it has to be an input to the pdl_interp.record_match operation, which is generated early during the pass such that its surrounding block can be referred to by branching operations. In consequence the value has to be materialized after the original pdl.apply_native_constraint has been deleted but before we get the chance to generate the corresponding pdl_interp.apply_constraint operation. We solve this by emitting a placeholder value when a ConstraintPosition is evaluated. These placeholder values (due to fusion there may be multiple for one constraint result) are replaced later when the actual pdl_interp.apply_constraint operation is created. Changes since the phabricator review: - Addressed all comments - In particular, removed registerConstraintFunctionWithResults and instead changed registerConstraintFunction so that contraint functions always have results (empty by default) - Thus we don't need to reuse `rewriteFunctions` to store constraint functions with results anymore, and can instead use `constraintFunctions` - Perform a stable sort of ConstraintQuestion, so that ConstraintQuestion appear before other ConstraintQuestion that use their results. - Don't create placeholders for pdl_interp::ApplyConstraintOp. Instead generate the `pdl_interp::ApplyConstraintOp` before generating the successor block. - Fixed a test failure in the pdl python bindings Original code by @martin-luecke Co-authored-by: martin-luecke List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

6d2b2b8eafbee4e35c9e666ca92d6d28f9253203 - [MLIR][PDL] Add Bytecode support for negated native constraints

Mon, 11 Sep 2023 12:57:41 +0000

[MLIR][PDL] Add Bytecode support for negated native constraintsDifferential Revision: https://reviews.llvm.org/D153878 List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

363b655920c49a4bcb0869f820ed40aac834eebd - Finish renaming getOperandSegmentSizeAttr() from `operand_segment_sizes` to `operandSegmentSizes`

Wed, 09 Aug 2023 19:47:13 +0000

Finish renaming getOperandSegmentSizeAttr() from `operand_segment_sizes` to `operandSegmentSizes`This renaming started with the native ODS support for properties, this is completing it.A mass automated textual rename seems safe for most codebases.Drop also the ods prefix to keep the accessors the same as they were beforethis change: properties.odsOperandSegmentSizesreverts back to: properties.operandSegementSizesThe ODS prefix was creating divergence between all the places and make it harder tobe consistent.Reviewed By: jpienaarDifferential Revision: https://reviews.llvm.org/D157173 List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

0a1569a400491e264060b8a6ff7b7f64e1865496 - [mlir][NFC] Remove trailing whitespaces from `.td` and `.mlir` files.

Mon, 28 Nov 2022 22:17:55 +0000

[mlir][NFC] Remove trailing whitespaces from `*.td` and `*.mlir` files.This is generated by running```sed --in-place 's/[[:space:]]\+$//' mlir/**/*.tdsed --in-place 's/[[:space:]]\+$//' mlir/**/*.mlir```Reviewed By: rriddle, dcaballeDifferential Revision: https://reviews.llvm.org/D138866 List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

ce57789d8e5dc109dc9bd330232b31a22a80ad3a - [mlir:PDL] Add support for creating ranges in rewrites

Fri, 09 Sep 2022 23:31:24 +0000

[mlir:PDL] Add support for creating ranges in rewritesThis commit adds support for building a concatenated range froma given set of elements, either single element or other ranges, within arewrite. We could conceptually extend this to support constraininginput ranges, but the logic there is quite a bit more complex so it isleft for later work when a need arises.Differential Revision: https://reviews.llvm.org/D133719 List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

58a47508f03546b4fce668fad751102b94feacfd - (Reland) [mlir] Switch segment size attributes to DenseI32ArrayAttr

Fri, 12 Aug 2022 19:43:03 +0000

(Reland) [mlir] Switch segment size attributes to DenseI32ArrayAttrThis reland includes changes to the Python bindings.Switch variadic operand and result segment size attributes to use thedense i32 array. Dense integer arrays were introduced primarily torepresent index lists. They are a better fit for segment sizes thandense elements attrs.Depends on D131801Reviewed By: rriddleDifferential Revision: https://reviews.llvm.org/D131803 List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

e8e718fa4b850d93a94ff47d55869401f0285d98 - Revert "[mlir] Switch segment size attributes to DenseI32ArrayAttr"

Fri, 12 Aug 2022 08:17:48 +0000

Revert "[mlir] Switch segment size attributes to DenseI32ArrayAttr"This reverts commit 30171e76f0e5ea8037bc4d1450dd3e12af4d9938.Breaks Python tests in MLIR, missing C API and Python changes. List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

30171e76f0e5ea8037bc4d1450dd3e12af4d9938 - [mlir] Switch segment size attributes to DenseI32ArrayAttr

Thu, 11 Aug 2022 07:01:35 +0000

[mlir] Switch segment size attributes to DenseI32ArrayAttrSwitch variadic operand and result segment size attributes to use thedense i32 array. Dense integer arrays were introduced primarily torepresent index lists. They are a better fit for segment sizes thandense elements attrs.Depends on D131738Reviewed By: mehdi_aminiDifferential Revision: https://reviews.llvm.org/D131702 List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

3c752289912895e067eb173485cadce6c618d6d4 - [mlir:PDLInterp] Refactor the implementation of result type inferrence

Tue, 26 Apr 2022 20:38:21 +0000

[mlir:PDLInterp] Refactor the implementation of result type inferrenceThe current implementation uses a discrete "pdl_interp.inferred_types"operation, which acts as a "fake" handle to a type range. This op isused as a signal to pdl_interp.create_operation that types should beinferred. This is terribly awkward and clunky though:* This op doesn't have a byte code representation, and its conversion to bytecode kind of assumes that it is only used in a certain way. The current lowering is also broken and seemingly untested.* Given that this is a different operation, it gives off the assumption that it can be used multiple times, or that after the first use the value contains the inferred types. This isn't the case though, the resultant type range can never actually be used as a type range.This commit refactors the representation by removing the discreteInferredTypesOp, and instead adds a UnitAttr topdl_interp.CreateOperation that signals when the created operationsshould infer their types. This leads to a much much cleaner abstraction,a more optimal bytecode lowering, and also allows for better errorhandling and diagnostics when a created operation doesn't actuallysupport type inferrence.Differential Revision: https://reviews.llvm.org/D124587 List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

ea64828a10e304f8131e40dfef062173fe606e6a - [mlir:PDL] Expand how native constraint/rewrite functions can be defined

Sat, 19 Mar 2022 22:08:09 +0000

[mlir:PDL] Expand how native constraint/rewrite functions can be definedThis commit refactors the expected form of native constraint and rewritefunctions, and greatly reduces the necessary user complexity required whendefining a native function. Namely, this commit adds in automatic processingof the necessary PDLValue glue code, and allows for users to defineconstraint/rewrite functions using the C++ types that they actually want touse.As an example, lets see a simple example rewrite defined today:```static void rewriteFn(PatternRewriter &rewriter, PDLResultList &results, ArrayRef args) { ValueRange operandValues = args[0].cast(); TypeRange typeValues = args[1].cast(); ... // Create an operation at some point and pass it back to PDL. Operation *op = rewriter.create(...); results.push_back(op);}```After this commit, that same rewrite could be defined as:```static Operation *rewriteFn(PatternRewriter &rewriter ValueRange operandValues, TypeRange typeValues) { ... // Create an operation at some point and pass it back to PDL. return rewriter.create(...);}```Differential Revision: https://reviews.llvm.org/D122086 List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

9595f3568ade92509d5f1e0d45066e31def762a6 - [mlir:PDL] Remove the ConstantParams support from native Constraints/Rewrites

Mon, 14 Mar 2022 05:09:20 +0000

[mlir:PDL] Remove the ConstantParams support from native Constraints/RewritesThis support has never really worked well, and is incredibly clunky touse (it effectively creates two argument APIs), and clunky to generate (it isn'tclear how we should actually expose this from PDL frontends). Treating theseas just attribute arguments is much much cleaner in every aspect of the stack.If we need to optimize lots of constant parameters, it would be better toinvestigate internal representation optimizations (e.g. batch attribute creation),that do not affect the user (we want a clean external API).Differential Revision: https://reviews.llvm.org/D121569 List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

f96a8675cd29776ca39bb76133ee9167f5001f17 - [mlir][PDL] Define a new PDLInterp::FuncOp operation and drop uses of FuncOp

Tue, 08 Mar 2022 22:20:08 +0000

[mlir][PDL] Define a new PDLInterp::FuncOp operation and drop uses of FuncOpDefining our own function operation allows for the PDL interpreterto be more self contained, and also removes any dependency on FuncOp;which is moving out of the Builtin dialect.Differential Revision: https://reviews.llvm.org/D121253 List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

3eb1647af036dc0e8370ed5a8b1ecbb5701f850b - Introduced iterative bytecode execution.

Fri, 26 Nov 2021 12:38:34 +0000

Introduced iterative bytecode execution.This is commit 2 of 4 for the multi-root matching in PDL, discussed in https://llvm.discourse.group/t/rfc-multi-root-pdl-patterns-for-kernel-matching/4148 (topic flagged for review).This commit implements the features needed for the execution of the new operations pdl_interp.get_accepting_ops, pdl_interp.choose_op:1. The implementation of the generation and execution of the two ops.2. The addition of Stack of bytecode positions within the ByteCodeExecutor. This is needed because in pdl_interp.choose_op, we iterate over the values returned by pdl_interp.get_accepting_ops until we reach finalize. When we reach finalize, we need to return back to the position marked in the stack.3. The functionality to extend the lifetime of values that cross the nondeterministic choice. The existing bytecode generator allocates the values to memory positions by representing the liveness of values as a collection of disjoint intervals over the matcher positions. This is akin to register allocation, and substantially reduces the footprint of the bytecode executor. However, because with iterative operation pdl_interp.choose_op, execution "returns" back, so any values whose original liveness cross the nondeterminstic choice must have their lifetime executed until finalize.Testing: pdl-bytecode.mlir testReviewed By: rriddle, MogballDifferential Revision: https://reviews.llvm.org/D108547 List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

85ab413b53aeb135eb58dab066afcbf20bef0cf8 - [mlir][PDL] Add support for variadic operands and results in the PDL byte code

Tue, 16 Mar 2021 20:12:01 +0000

[mlir][PDL] Add support for variadic operands and results in the PDL byte codeSupporting ranges in the byte code requires additional complexity, given that a range can't be easily representable as an opaque void *, as is possible with the existing bytecode value types (Attribute, Type, Value, etc.). To enable representing a range with void *, an auxillary storage is used for the actual range itself, with the pointer being passed around in the normal byte code memory. For type ranges, a TypeRange is stored. For value ranges, a ValueRange is stored. The above problem represents a majority of the complexity involved in this revision, the rest is adapting/adding byte code operations to support the changes made to the PDL interpreter in the parent revision.After this revision, PDL will have initial end-to-end support for variadic operands/results.Differential Revision: https://reviews.llvm.org/D95723 List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

3a833a0e0e526d4ef3f0037eaa2ace3511f216ce - [mlir][PDL] Add support for variadic operands and results in the PDL Interpreter

Tue, 16 Mar 2021 20:11:50 +0000

[mlir][PDL] Add support for variadic operands and results in the PDL InterpreterThis revision extends the PDL Interpreter dialect to add support for variadic operands and results, with ranges of these values represented via the recently added !pdl.range type. To support this extension, three new operations have been added that closely match the single variant:* pdl_interp.check_types : Compare a range of types with a known range.* pdl_interp.create_types : Create a constant range of types.* pdl_interp.get_operands : Get a range of operands from an operation.* pdl_interp.get_results : Get a range of results from an operation.* pdl_interp.switch_types : Switch on a range of types.This revision handles adding support in the interpreter dialect and the conversion from PDL to PDLInterp. Support for variadic operands and results in the bytecode will be added in a followup revision.Differential Revision: https://reviews.llvm.org/D95722 List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

02c4c0d5b2adc79c122bd2662a4458f75771aecf - [mlir][pdl] Remove CreateNativeOp in favor of a more general ApplyNativeRewriteOp.

Tue, 16 Mar 2021 20:11:22 +0000

[mlir][pdl] Remove CreateNativeOp in favor of a more general ApplyNativeRewriteOp.This has a numerous amount of benefits, given the overly clunky nature of CreateNativeOp:* Users can now call into arbitrary rewrite functions from inside of PDL, allowing for more natural interleaving of PDL/C++ and enabling for more of the pattern to be in PDL.* Removes the need for an additional set of C++ functions/registry/etc. The new ApplyNativeRewriteOp will use the same PDLRewriteFunction as the existing RewriteOp. This reduces the API surface area exposed to users.This revision also introduces a new PDLResultList class. This class is used to provide results of native rewrite functions back to PDL. We introduce a new class instead of using a SmallVector to simplify the work necessary for variadics, given that ranges will require some changes to the structure of PDLValue.Differential Revision: https://reviews.llvm.org/D95720 List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir

abfd1a8b3bc5ad8516a83c3ae7ba9f16032525ad - [mlir][PDL] Add support for PDL bytecode and expose PDL support to OwningRewritePatternList

Tue, 01 Dec 2020 22:30:18 +0000

[mlir][PDL] Add support for PDL bytecode and expose PDL support to OwningRewritePatternListPDL patterns are now supported via a new `PDLPatternModule` class. This class contains a ModuleOp with the pdl::PatternOp operations representing the patterns, as well as a collection of registered C++ functions for native constraints/creations/rewrites/etc. that may be invoked via the pdl patterns. Instances of this class are added to an OwningRewritePatternList in the same fashion as C++ RewritePatterns, i.e. via the `insert` method.The PDL bytecode is an in-memory representation of the PDL interpreter dialect that can be efficiently interpreted/executed. The representation of the bytecode boils down to a code array(for opcodes/memory locations/etc) and a memory buffer(for storing attributes/operations/values/any other data necessary). The bytecode operations are effectively a 1-1 mapping to the PDLInterp dialect operations, with a few exceptions in cases where the in-memory representation of the bytecode can be more efficient than the MLIR representation. For example, a generic `AreEqual` bytecode op can be used to represent AreEqualOp, CheckAttributeOp, and CheckTypeOp.The execution of the bytecode is split into two phases: matching and rewriting. When matching, all of the matched patterns are collected to avoid the overhead of re-running parts of the matcher. These matched patterns are then considered alongside the native C++ patterns, which rewrite immediately in-place via `RewritePattern::matchAndRewrite`, for the given root operation. When a PDL pattern is matched and has the highest benefit, it is passed back to the bytecode to execute its rewriter.Differential Revision: https://reviews.llvm.org/D89107 List of files: /llvm-project/mlir/test/Rewrite/pdl-bytecode.mlir