| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir] Remove support for non-prefixed accessors This finishes off a year long pursuit to LLVMify the generated operation accessors, prefixing them with get/set. Support for any other accessor naming is fully removed after this commit. https://discourse.llvm.org/t/psa-raw-accessors-are-being-removed/65629 Differential Revision: https://reviews.llvm.org/D136727 | 3 年前 | |
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. | 2 年前 | |
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. | 2 年前 | |
[mlir][PDLL] Add support for generating PDL patterns from PDLL at build time This essentially sets up mlir-pdll to function in a similar manner to mlir-tblgen. Aside from the boilerplate of configuring CMake and setting up a basic initial test, two new options are added to mlir-pdll to mirror options provided by tblgen: * -d This option generates a dependency file (i.e. a set of build time dependencies) while processing the input file. * --write-if-changed This option only writes to the output file if the data would have changed, which for the build system prevents unnecesarry rebuilds if the file was touched but not actually changed. Differential Revision: https://reviews.llvm.org/D124075 | 4 年前 | |
[PDLL] Add support for tablegen includes and importing ODS information This commit adds support for processing tablegen include files, and importing various information from ODS. This includes operations, attribute+type constraints, attribute/operation/type interfaces, etc. This will allow for much more robust tooling, and also allows for referencing ODS constructs directly within PDLL (imported interfaces can be used as constraints, operation result names can be used for member access, etc). Differential Revision: https://reviews.llvm.org/D119900 | 4 年前 | |
[PDLL]: Fix crash when negation doesn't apply to native constraint (#84331) Fixes that Pattern { let tuple = (attr<"3 : i34">); not tuple.0; erase _; } would crash the PDLL parser because it expected a native constraint after not. | 2 年前 | |
[MLIR][PDL] Add PDLL support for negated native constraints This commit enables the expression of negated native constraints in PDLL: If a constraint is prefixed with "not" it is parsed as a negated constraint and hence the attribute isNegated of the emitted pdl.apply_native_constraint operation is set to true. In first instance this is only supported for the calling of external native C++ constraints and generation of PDL patterns. Previously, negating a native constraint would have been handled by creating an additional native call, e.g. PDLL Constraint checkA(input: Attr); Constarint checkNotA(input: Attr); or by including an explicit additional operand for negation, e.g. Constraint checkA(input: Attr, negated: Attr); With this a constraint can simply be negated by prefixing it with not. e.g. PDLL Constraint simpleConstraint(op: Op); Pattern example { let inputOp = op<test.bar>() ->(type: Type); let root = op<test.foo>(inputOp.0) -> (); not simpleConstraint(inputOp); simpleConstraint(root); erase root; } Depends on [[ https://reviews.llvm.org/D153871 | D153871 ]] Reviewed By: Mogball Differential Revision: https://reviews.llvm.org/D153959 | 2 年前 | |
[mlir][PDLL] Add an initial frontend for PDLL This is a new pattern rewrite frontend designed from the ground up to support MLIR constructs, and to target PDL. This frontend language was proposed in https://llvm.discourse.group/t/rfc-pdll-a-new-declarative-rewrite-frontend-for-mlir/4798 This commit starts sketching out the base structure of the frontend, and is intended to be a minimal starting point for building up the language. It essentially contains support for defining a pattern, variables, and erasing an operation. The features mentioned in the proposal RFC (including IDE support) will be added incrementally in followup commits. I intend to upstream the documentation for the language in a followup when a bit more of the pieces have been landed. Differential Revision: https://reviews.llvm.org/D115093 | 4 年前 | |
[mlir] Move casting method calls to function calls The MLIR classes Type/Attribute/Operation/Op/Value support cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast functionality in addition to defining methods with the same name. This change continues the migration of uses of the method to the corresponding function call as has been decided as more consistent. This commit attempts to update all occurrences of the casts in .td files, although it is likely that a couple were missed. Context: - https://mlir.llvm.org/deprecation/ at "Use the free function variants for dyn_cast/cast/isa/…" - Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443 Implementation: Unfortunatley, this was not automated, but was handled by mindlessly going to next occurrences of patterns, selecting the piece of code to be moved into the function call, and running a vim macro over the span of around 4 hours. Differential Revision: https://reviews.llvm.org/D150199 | 3 年前 | |
[PDLL] Add support for user defined constraint and rewrite functions These functions allow for defining pattern fragments usable within the match and rewrite sections of a pattern. The main structure of Constraints and Rewrites functions are the same, and are similar to functions in other languages; they contain a signature (i.e. name, argument list, result list) and a body: pdll // Constraint that takes a value as an input, and produces a value: Constraint Cst(arg: Value) -> Value { ... } // Constraint that returns multiple values: Constraint Cst() -> (result1: Value, result2: ValueRange); When returning multiple results, each result can be optionally be named (the result of a Constraint/Rewrite in the case of multiple results is a tuple). These body of a Constraint/Rewrite functions can be specified in several ways: * Externally In this case we are importing an external function (registered by the user outside of PDLL): pdll Constraint Foo(op: Op); Rewrite Bar(); * In PDLL (using PDLL constructs) In this case, the body is defined using PDLL constructs: pdll Rewrite BuildFooOp() { // The result type of the Rewrite is inferred from the return. return op<my_dialect.foo>; } // Constraints/Rewrites can also implement a lambda/expression // body for simple one line bodies. Rewrite BuildFooOp() => op<my_dialect.foo>; * In PDLL (using a native/C++ code block) In this case the body is specified using a C++(or potentially other language at some point) code block. When building PDLL in AOT mode this will generate a native constraint/rewrite and register it with the PDL bytecode. pdll Rewrite BuildFooOp() -> Op<my_dialect.foo> [{ return rewriter.create<my_dialect::FooOp>(...); }]; Differential Revision: https://reviews.llvm.org/D115836 | 4 年前 | |
[PDLL] Add support for single line lambda-like patterns This allows for defining simple patterns in a single line. The lambda body of a Pattern expects a single operation rewrite statement: Pattern => replace op<my_dialect.foo>(operands: ValueRange) with operands; Differential Revision: https://reviews.llvm.org/D115835 | 4 年前 | |
[mlir:PDLL] Allow complex constraints on Rewrite arguments/results The documentation already has examples of this, and it allows for using nicer C++ types when defining native Rewrites. Differential Revision: https://reviews.llvm.org/D133989 | 3 年前 | |
[PDLL] Add support for user defined constraint and rewrite functions These functions allow for defining pattern fragments usable within the match and rewrite sections of a pattern. The main structure of Constraints and Rewrites functions are the same, and are similar to functions in other languages; they contain a signature (i.e. name, argument list, result list) and a body: pdll // Constraint that takes a value as an input, and produces a value: Constraint Cst(arg: Value) -> Value { ... } // Constraint that returns multiple values: Constraint Cst() -> (result1: Value, result2: ValueRange); When returning multiple results, each result can be optionally be named (the result of a Constraint/Rewrite in the case of multiple results is a tuple). These body of a Constraint/Rewrite functions can be specified in several ways: * Externally In this case we are importing an external function (registered by the user outside of PDLL): pdll Constraint Foo(op: Op); Rewrite Bar(); * In PDLL (using PDLL constructs) In this case, the body is defined using PDLL constructs: pdll Rewrite BuildFooOp() { // The result type of the Rewrite is inferred from the return. return op<my_dialect.foo>; } // Constraints/Rewrites can also implement a lambda/expression // body for simple one line bodies. Rewrite BuildFooOp() => op<my_dialect.foo>; * In PDLL (using a native/C++ code block) In this case the body is specified using a C++(or potentially other language at some point) code block. When building PDLL in AOT mode this will generate a native constraint/rewrite and register it with the PDL bytecode. pdll Rewrite BuildFooOp() -> Op<my_dialect.foo> [{ return rewriter.create<my_dialect::FooOp>(...); }]; Differential Revision: https://reviews.llvm.org/D115836 | 4 年前 | |
[mlir] Move the Builtin FuncOp to the Func dialect This commit moves FuncOp out of the builtin dialect, and into the Func dialect. This move has been planned in some capacity from the moment we made FuncOp an operation (years ago). This commit handles the functional aspects of the move, but various aspects are left untouched to ease migration: func::FuncOp is re-exported into mlir to reduce the actual API churn, the assembly format still accepts the unqualified func. These temporary measures will remain for a little while to simplify migration before being removed. Differential Revision: https://reviews.llvm.org/D121266 | 4 年前 | |
[PDLL] Add a rewrite statement to enable complex rewrites The rewrite statement allows for rewriting a given root operation with a block of nested rewriters. The root operation is not implicitly erased or replaced, and any transformations to it must be expressed within the nested rewrite block. The inner body may contain any number of other rewrite statements, variables, or expressions. Differential Revision: https://reviews.llvm.org/D115299 | 4 年前 | |
[mlir:PDLL] Fix error handling of eof within a string literal We currently aren't handling this properly, and in the case of a string block just crash. This commit adds proper error handling and detection for eof. Differential Revision: https://reviews.llvm.org/D124585 | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 |