| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
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 before this change: properties.odsOperandSegmentSizes reverts back to: properties.operandSegementSizes The ODS prefix was creating divergence between all the places and make it harder to be consistent. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D157173 | 2 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir][arith] Add missing canon pattern trunci(ext*i(x)) -> ext*i(x) This pattern triggers when only the extension bits are truncated. Reviewed By: dcaballe Differential Revision: https://reviews.llvm.org/D149286 | 3 年前 | |
[mlir] make memref.subview produce strided layout Memref subview operation has been initially designed to work on memrefs with strided layouts only and has never supported anything else. Port it to use the recently added StridedLayoutAttr instead of extracting the strided from implicitly from affine maps. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D133938 | 3 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[MLIR] Don't sort operand of commutative ops when comparing two ops as there is a correctness issue This feature was introduced in D123492. Doing equivalence on pointers to sort operands of commutative operations is incorrect when checking equivalence of ops in separate regions (where the lhs and rhs operands are marked as equivalent but are not the same value). It was also discussed in D123492 and D129480 that the correct solution would be to stable sort the operands in canonicalization (based on some numbering in the region maybe), but until that lands, reverting this change will unblock us and other users. An example of a pass that might not work properly because of this is DuplicateFunctionEliminationPass. Reviewed By: mehdi_amini, jpienaar Differential Revision: https://reviews.llvm.org/D154699 | 2 年前 | |
Introduce MLIR Op Properties This new features enabled to dedicate custom storage inline within operations. This storage can be used as an alternative to attributes to store data that is specific to an operation. Attribute can also be stored inside the properties storage if desired, but any kind of data can be present as well. This offers a way to store and mutate data without uniquing in the Context like Attribute. See the OpPropertiesTest.cpp for an example where a struct with a std::vector<> is attached to an operation and mutated in-place: struct TestProperties { int a = -1; float b = -1.; std::vector<int64_t> array = {-33}; }; More complex scheme (including reference-counting) are also possible. The only constraint to enable storing a C++ object as "properties" on an operation is to implement three functions: - convert from the candidate object to an Attribute - convert from the Attribute to the candidate object - hash the object Optional the parsing and printing can also be customized with 2 extra functions. A new options is introduced to ODS to allow dialects to specify: let usePropertiesForAttributes = 1; When set to true, the inherent attributes for all the ops in this dialect will be using properties instead of being stored alongside discardable attributes. The TestDialect showcases this feature. Another change is that we introduce new APIs on the Operation class to access separately the inherent attributes from the discardable ones. We envision deprecating and removing the getAttr(), getAttrsDictionary(), and other similar method which don't make the distinction explicit, leading to an entirely separate namespace for discardable attributes. Recommit d572cd1b067f after fixing python bindings build. Differential Revision: https://reviews.llvm.org/D141742 | 3 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][core] Fix inline pass default pipeline dump The inliner pass performs canonicalization when created programtically, run with mlir-opt with default options, or when explicitly specified. However, when running the pipeline resulting from a -dump-pass-pipeline on a default inline pass, the canonicalization is not performed as part of the inlining. This is because the default value for the default-pipeline option of the inline pass is an empty string, and this is selected during the dumping. When InlinerPass::initializeOptions detects the empty string, it sets the defaultPipeline to nullptr, which was previously set to canonicalize in the InlinerPass constructor, thus the canonicalization is not performed. The added test checks if the inline pass performs canonicalization by default, and that the dumped default-pipeline is set to canonicalize. Fixes: https://github.com/llvm/llvm-project/issues/60960 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D145066 | 3 年前 | |
[mlir][Inliner] Support recursion in Inliner This fixes Bug https://github.com/llvm/llvm-project/issues/53492 and uses InlineHistory to track recursive inlining. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D127072 | 3 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir] Argument and result attribute handling during inlining. The revision adds the handleArgument and handleResult handlers that allow users of the inlining interface to implement argument and result conversions that take argument and result attributes into account. The motivating use cases for this revision are taken from the LLVM dialect inliner, which has to copy arguments that are marked as byval and that also has to consider zeroext / signext when converting integers. All type conversions are currently handled by the materializeCallConversion hook. It runs before isLegalToInline and supports only the introduction of a single cast operation since it may have to rollback. The new handlers run shortly before and after inlining and cannot fail. As a result, they can introduce more complex ir such as copying a struct argument. At the moment, the new hooks cannot be used to perform type conversions since all type conversions have to be done using the materializeCallConversion. A follow up revision will either relax this constraint or drop materializeCallConversion in favor of the new and more flexible handlers. The revision also extends the CallableOpInterface to provide access to the argument and result attributes if available. Reviewed By: rriddle, Dinistro Differential Revision: https://reviews.llvm.org/D145582 | 3 年前 | |
[MLIR] Clarify (test-scf-)parallel-loop-collapsing 1. parallel-loop-collapsing is renamed to test-scf-parallel-loop-collapsing. 2. The pass adds various checks to provide error messages instead of hitting assert failures. 3. Testing is added to verify these error messages This is roughly an NFC. The name changes, but all checked behavior previously would have resulted in an assertion failure. Almost no new support is added, so this pass is still limited in scope to testing the transform behaves correctly with input arguments that perfectly match the ParallelLoop's iterator arg set. The one new piece of functionality is that invalid operations will now be skipped with an error messages instead of producing an assertion failure, so the pass can be used with expected failures for pieces of the IR not cared about with a specific RUN command. Differential Revision: https://reviews.llvm.org/D147514 | 3 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][test] NFC - Fix some worst offenders "capture by SSA name" tests Many tests still depend on specific names of SSA values (!!). This commit is a best effort cleanup that will set the stage for adding some pretty SSA result names. | 3 年前 | |
[mlir][NFC] Remove trailing whitespaces from *.td and *.mlir files. This is generated by running sed --in-place 's/[[:space:]]\+$//' mlir/**/*.td sed --in-place 's/[[:space:]]\+$//' mlir/**/*.mlir Reviewed By: rriddle, dcaballe Differential Revision: https://reviews.llvm.org/D138866 | 3 年前 | |
[mlir] Add a utility function to make a region isolated from above. The utility functions takes a region and makes it isolated from above by appending to the entry block arguments that represent the captured values and replacing all uses of the captured values within the region with the newly added arguments. The captures values are returned. The utility function also takes an optional callback that allows cloning operations that define the captured values into the region during the process of making it isolated from above. The cloned value is no longer a captured values. The operands of the operation are then captured values. This is done transitively allow cloning of a DAG of operations into the region based on the callback. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D148684 | 3 年前 | |
[mlir][Analysis][NFC] Split FlatAffineValueConstraints into multiple classes The new class hierarchy is as follows: * IntegerRelation (no change) * IntegerPolyhedron (no change) * FlatLinearConstraints: provides an AffineExpr-based API * FlatLinearValueConstraints: stores an additional mapping of non-local vars to SSA values * FlatAffineValueConstraints: provides additional helper functions for Affine dialect ops * FlatAffineRelation (no change) FlatConstraints and FlatValueConstraints are moved from MLIRAffineAnalysis to MLIRAnalysis and can be used without depending on the Affine dialect. This change is in preparation of D145681, which adds an MLIR interface that depends on FlatConstraints (and cannot depend on the Affine dialect or any other dialect). Differential Revision: https://reviews.llvm.org/D146201 | 3 年前 | |
[mlir][Analysis][NFC] Split FlatAffineValueConstraints into multiple classes The new class hierarchy is as follows: * IntegerRelation (no change) * IntegerPolyhedron (no change) * FlatLinearConstraints: provides an AffineExpr-based API * FlatLinearValueConstraints: stores an additional mapping of non-local vars to SSA values * FlatAffineValueConstraints: provides additional helper functions for Affine dialect ops * FlatAffineRelation (no change) FlatConstraints and FlatValueConstraints are moved from MLIRAffineAnalysis to MLIRAnalysis and can be used without depending on the Affine dialect. This change is in preparation of D145681, which adds an MLIR interface that depends on FlatConstraints (and cannot depend on the Affine dialect or any other dialect). Differential Revision: https://reviews.llvm.org/D146201 | 3 年前 | |
[MLIR] Clarify (test-scf-)parallel-loop-collapsing 1. parallel-loop-collapsing is renamed to test-scf-parallel-loop-collapsing. 2. The pass adds various checks to provide error messages instead of hitting assert failures. 3. Testing is added to verify these error messages This is roughly an NFC. The name changes, but all checked behavior previously would have resulted in an assertion failure. Almost no new support is added, so this pass is still limited in scope to testing the transform behaves correctly with input arguments that perfectly match the ParallelLoop's iterator arg set. The one new piece of functionality is that invalid operations will now be skipped with an error messages instead of producing an assertion failure, so the pass can be used with expected failures for pieces of the IR not cared about with a specific RUN command. Differential Revision: https://reviews.llvm.org/D147514 | 3 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir] Make division unsigned. Uses arith.divui where it is safe to do so. Adjusts the tests for above. Differential Revision: https://reviews.llvm.org/D132701 | 3 年前 | |
Fix MLIR test after 6eca120dd8d3e | 3 年前 | |
[mlir] PromoteBuffersToStackPass - Copy attributes of original AllocOp Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D143185 | 3 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
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 before this change: properties.odsOperandSegmentSizes reverts back to: properties.operandSegementSizes The ODS prefix was creating divergence between all the places and make it harder to be consistent. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D157173 | 2 年前 | |
[mlir] Remove special case parsing/printing of func operations This was leftover from when the standard dialect was destroyed, and when FuncOp moved to the func dialect. Now that these transitions have settled a bit we can drop these. Most updates were handled using a simple regex: replace ^( *)func with $1func.func Differential Revision: https://reviews.llvm.org/D124146 | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][SCF] Add utility method to add new yield values to a loop. The current implementation of cloneWithNewYields has a few issues - It clones the loop body of the original loop to create a new loop. This is very expensive. - It performs erase operations which are incompatible when this method is called from within a pattern rewrite. All erases need to go through PatternRewriter. To address these a new utility method replaceLoopWithNewYields is added which - moves the operations from the original loop into the new loop. - replaces all uses of the original loop with the corresponding results of the new loop - use a call back to allow caller to generate the new yield values. - the original loop is modified to just yield the basic block arguments corresponding to the iter_args of the loop. This represents a no-op loop. The loop itself is dead (since all its uses are replaced), but is not removed. The caller is expected to erase the op. Consequently, this method can be called from within a matchAndRewrite method of a PatternRewriter. The cloneWithNewYields could be replaces with replaceLoopWithNewYields, but that seems to trigger a failure during walks, potentially due to the operations being moved. That is left as a TODO. Differential Revision: https://reviews.llvm.org/D125147 | 4 年前 | |
[MLIR] Clarify (test-scf-)parallel-loop-collapsing 1. parallel-loop-collapsing is renamed to test-scf-parallel-loop-collapsing. 2. The pass adds various checks to provide error messages instead of hitting assert failures. 3. Testing is added to verify these error messages This is roughly an NFC. The name changes, but all checked behavior previously would have resulted in an assertion failure. Almost no new support is added, so this pass is still limited in scope to testing the transform behaves correctly with input arguments that perfectly match the ParallelLoop's iterator arg set. The one new piece of functionality is that invalid operations will now be skipped with an error messages instead of producing an assertion failure, so the pass can be used with expected failures for pieces of the IR not cared about with a specific RUN command. Differential Revision: https://reviews.llvm.org/D147514 | 3 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[MLIR] Add a utility to sort the operands of commutative ops Added a commutativity utility pattern and a function to populate it. The pattern sorts the operands of an op in ascending order of the "key" associated with each operand iff the op is commutative. This sorting is stable. The function is intended to be used inside passes to simplify the matching of commutative operations. After the application of the above-mentioned pattern, since the commutative operands now have a deterministic order in which they occur in an op, the matching of large DAGs becomes much simpler, i.e., requires much less number of checks to be written by a user in her/his pattern matching function. The "key" associated with an operand is the list of the "AncestorKeys" associated with the ancestors of this operand, in a breadth-first order. The operand of any op is produced by a set of ops and block arguments. Each of these ops and block arguments is called an "ancestor" of this operand. Now, the "AncestorKey" associated with: 1. A block argument is {type: BLOCK_ARGUMENT, opName: ""}. 2. A non-constant-like op, for example, arith.addi, is {type: NON_CONSTANT_OP, opName: "arith.addi"}. 3. A constant-like op, for example, arith.constant, is {type: CONSTANT_OP, opName: "arith.constant"}. So, if an operand, say A, was produced as follows: `` <block argument> <block argument> \ / \ / arith.subi arith.constant \ / arith.addi | returns A ` Then, the block arguments and operations present in the backward slice of A, in the breadth-first order are: arith.addi, arith.subi, arith.constant, <block argument>, and <block argument>. Thus, the "key" associated with operand A is: { {type: NON_CONSTANT_OP, opName: "arith.addi"}, {type: NON_CONSTANT_OP, opName: "arith.subi"}, {type: CONSTANT_OP, opName: "arith.constant"}, {type: BLOCK_ARGUMENT, opName: ""}, {type: BLOCK_ARGUMENT, opName: ""} } Now, if "keyA" is the key associated with operand A and "keyB" is the key associated with operand B, then: "keyA" < "keyB" iff: 1. In the first unequal pair of corresponding AncestorKeys, the AncestorKey in operand A is smaller, or, 2. Both the AncestorKeys in every pair are the same and the size of operand A's "key" is smaller. AncestorKeys of type BLOCK_ARGUMENT are considered the smallest, those of type CONSTANT_OP, the largest, and NON_CONSTANT_OP types come in between. Within the types NON_CONSTANT_OP and CONSTANT_OP, the smaller ones are the ones with smaller op names (lexicographically). --- Some examples of such a sorting: Assume that the sorting is being applied to foo.commutative, which is a commutative op. Example 1: > %1 = foo.const 0 > %2 = foo.mul <block argument>, <block argument> > %3 = foo.commutative %1, %2 Here, 1. The key associated with %1 is: { {CONSTANT_OP, "foo.const"} } 2. The key associated with %2 is: { {NON_CONSTANT_OP, "foo.mul"}, {BLOCK_ARGUMENT, ""}, {BLOCK_ARGUMENT, ""} } The key of %2 < the key of %1 Thus, the sorted foo.commutative is: > %3 = foo.commutative %2, %1 Example 2: > %1 = foo.const 0 > %2 = foo.mul <block argument>, <block argument> > %3 = foo.mul %2, %1 > %4 = foo.add %2, %1 > %5 = foo.commutative %1, %2, %3, %4 Here, 1. The key associated with %1 is: { {CONSTANT_OP, "foo.const"} } 2. The key associated with %2 is: { {NON_CONSTANT_OP, "foo.mul"}, {BLOCK_ARGUMENT, ""} } 3. The key associated with %3 is: { {NON_CONSTANT_OP, "foo.mul"}, {NON_CONSTANT_OP, "foo.mul"}, {CONSTANT_OP, "foo.const"}, {BLOCK_ARGUMENT, ""}, {BLOCK_ARGUMENT, ""} } 4. The key associated with %4 is: { {NON_CONSTANT_OP, "foo.add"}, {NON_CONSTANT_OP, "foo.mul"}, {CONSTANT_OP, "foo.const"}, {BLOCK_ARGUMENT, ""}, {BLOCK_ARGUMENT, ""} } Thus, the sorted foo.commutative` is: > %5 = foo.commutative %4, %3, %2, %1 Signed-off-by: Srishti Srivastava <srishti.srivastava@polymagelabs.com> Reviewed By: Mogball Differential Revision: https://reviews.llvm.org/D124750 | 3 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir:PDL] Add support for DialectConversion with pattern configurations Up until now PDL(L) has not supported dialect conversion because we had no way of remapping values or integrating with type conversions. This commit rectifies that by adding a new "pattern configuration" concept to PDL. This essentially allows for attaching external configurations to patterns, which can hook into pattern events (for now just the scope of a rewrite, but we could also pass configs to native rewrites as well). This allows for injecting the type converter into the conversion pattern rewriter. Differential Revision: https://reviews.llvm.org/D133142 | 3 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir] Remove special case parsing/printing of func operations This was leftover from when the standard dialect was destroyed, and when FuncOp moved to the func dialect. Now that these transitions have settled a bit we can drop these. Most updates were handled using a simple regex: replace ^( *)func with $1func.func Differential Revision: https://reviews.llvm.org/D124146 | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir] Check FunctionOpInterface castable type As convertFuncOpTypes does not support other FuncOpInterface types, we should check the type to avoid assertion failure. The original issue was reported https://github.com/llvm/llvm-project/issues/61858. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D148873 | 3 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
Introduce MLIR Op Properties This new features enabled to dedicate custom storage inline within operations. This storage can be used as an alternative to attributes to store data that is specific to an operation. Attribute can also be stored inside the properties storage if desired, but any kind of data can be present as well. This offers a way to store and mutate data without uniquing in the Context like Attribute. See the OpPropertiesTest.cpp for an example where a struct with a std::vector<> is attached to an operation and mutated in-place: struct TestProperties { int a = -1; float b = -1.; std::vector<int64_t> array = {-33}; }; More complex scheme (including reference-counting) are also possible. The only constraint to enable storing a C++ object as "properties" on an operation is to implement three functions: - convert from the candidate object to an Attribute - convert from the Attribute to the candidate object - hash the object Optional the parsing and printing can also be customized with 2 extra functions. A new options is introduced to ODS to allow dialects to specify: let usePropertiesForAttributes = 1; When set to true, the inherent attributes for all the ops in this dialect will be using properties instead of being stored alongside discardable attributes. The TestDialect showcases this feature. Another change is that we introduce new APIs on the Operation class to access separately the inherent attributes from the discardable ones. We envision deprecating and removing the getAttr(), getAttrsDictionary(), and other similar method which don't make the distinction explicit, leading to an entirely separate namespace for discardable attributes. Recommit d572cd1b067f after fixing python bindings build. Differential Revision: https://reviews.llvm.org/D141742 | 3 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][Interfaces] Symbols are not trivially dead The greedy pattern rewrite driver removes ops that are "trivially dead". This could include symbols that are still referenced by other ops. Dead symbols should be removed with the -symbol-dce pass instead. This bug was not triggered for func::FuncOp, because ops are not considered "trivally dead" if they do not implement the MemoryEffectOpInterface, indicating that the op may or may not have side effects. It is, however, triggered for transform::NamedSequenceOp, which implements that interface because it is required for all transform dialect ops. Differential Revision: https://reviews.llvm.org/D152994 | 3 年前 | |
Introduce MLIR Op Properties This new features enabled to dedicate custom storage inline within operations. This storage can be used as an alternative to attributes to store data that is specific to an operation. Attribute can also be stored inside the properties storage if desired, but any kind of data can be present as well. This offers a way to store and mutate data without uniquing in the Context like Attribute. See the OpPropertiesTest.cpp for an example where a struct with a std::vector<> is attached to an operation and mutated in-place: struct TestProperties { int a = -1; float b = -1.; std::vector<int64_t> array = {-33}; }; More complex scheme (including reference-counting) are also possible. The only constraint to enable storing a C++ object as "properties" on an operation is to implement three functions: - convert from the candidate object to an Attribute - convert from the Attribute to the candidate object - hash the object Optional the parsing and printing can also be customized with 2 extra functions. A new options is introduced to ODS to allow dialects to specify: let usePropertiesForAttributes = 1; When set to true, the inherent attributes for all the ops in this dialect will be using properties instead of being stored alongside discardable attributes. The TestDialect showcases this feature. Another change is that we introduce new APIs on the Operation class to access separately the inherent attributes from the discardable ones. We envision deprecating and removing the getAttr(), getAttrsDictionary(), and other similar method which don't make the distinction explicit, leading to an entirely separate namespace for discardable attributes. Recommit d572cd1b067f after fixing python bindings build. Differential Revision: https://reviews.llvm.org/D141742 | 3 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir] Remove special case parsing/printing of func operations This was leftover from when the standard dialect was destroyed, and when FuncOp moved to the func dialect. Now that these transitions have settled a bit we can drop these. Most updates were handled using a simple regex: replace ^( *)func with $1func.func Differential Revision: https://reviews.llvm.org/D124146 | 4 年前 | |
[mlir] Add RewriterBase::replaceAllUsesWith for Blocks. When changing IR in a RewriterPattern, all changes must go through the rewriter. There are several convenience functions in RewriterBase that help with high-level modifications, such as replaceAllUsesWith for Values, but there is currently none to do the same task for Blocks. Reviewed By: mehdi_amini, ingomueller-net Differential Revision: https://reviews.llvm.org/D142525 | 3 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir][NFC] Update textual references of func to func.func in Transform tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][transforms] TopologicalSort: Support ops from different blocks This change allows analyzing ops from different block, in particular when used in programs that have cf branches. Differential Revision: https://reviews.llvm.org/D135644 | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 4 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 |