MMehdi AminiFix MLIR test pass crash
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[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] 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 年前 | |
Fix MLIR test pass crash The pass tried to fold in reverse-post-order, but it cause an issue when a parent is folded before the chilren as they will still be present in the worklist. Use reverse-preorder instead here. Fixes #64089 | 2 年前 | |
[mlir:NFC] Remove the forward declaration of FuncOp in the mlir namespace FuncOp has been moved to the func namespace for a little over a month, the using directive can be dropped now. | 4 年前 | |
mlir/DialectConversion: use std::optional (NFC) This is part of an effort to migrate from llvm::Optional to std::optional. This patch touches DialectConversion, and modifies existing conversions and tests appropriately. See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 Signed-off-by: Ramkumar Ramachandra <r@artagnon.com> Differential Revision: https://reviews.llvm.org/D140303 | 3 年前 | |
[mlir:PDLL] Don't require users to provide operands/results when all are variadic When all operands or results are variadic, zero values is a perfectly valid behavior to expect, and we shouldn't force the user to provide values in this case. For example, when creating a call or a return operation we often don't want/need to provide return values. Differential Revision: https://reviews.llvm.org/D133721 | 3 年前 | |
[mlir] Add operations to BlockAndValueMapping and rename it to IRMapping The patch adds operations to BlockAndValueMapping and renames it to IRMapping. When operations are cloned, old operations are mapped to the cloned operations. This allows mapping from an operation to a cloned operation. Example: Operation *opWithRegion = ... Operation *opInsideRegion = &opWithRegion->front().front(); IRMapping map Operation *newOpWithRegion = opWithRegion->clone(map); Operation *newOpInsideRegion = map.lookupOrNull(opInsideRegion); Migration instructions: All includes to mlir/IR/BlockAndValueMapping.h should be replaced with mlir/IR/IRMapping.h. All uses of BlockAndValueMapping need to be renamed to IRMapping. Reviewed By: rriddle, mehdi_amini Differential Revision: https://reviews.llvm.org/D139665 | 3 年前 | |
[mlir][Transforms][NFC] Improve builder/listener API of OperationFolder The constructor of OperationFolder takes a listener. Therefore, the remaining API should not take any builder/rewriters. This could lead to double notifications in case a listener is attached to the builder/rewriter. As an internal cleanup, OperationFolder now has an IRRewriter instead of a RewriterBase::Listener. In most cases, OperationFolder no longer has to notify/deal with listeners. This is done by the rewriter. Differential Revision: https://reviews.llvm.org/D146134 | 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] Move casting calls from methods 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 begins the migration of uses of the method to the corresponding function call as has been decided as more consistent. Note that there still exist classes that only define methods directly, such as AffineExpr, and this does not include work currently to support a functional cast/isa call. Caveats include: - This clang-tidy script probably has more problems. - This only touches C++ code, so nothing that is being generated. 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: This first patch was created with the following steps. The intention is to only do automated changes at first, so I waste less time if it's reverted, and so the first mass change is more clear as an example to other teams that will need to follow similar steps. Steps are described per line, as comments are removed by git: 0. Retrieve the change from the following to build clang-tidy with an additional check: https://github.com/llvm/llvm-project/compare/main...tpopp:llvm-project:tidy-cast-check 1. Build clang-tidy 2. Run clang-tidy over your entire codebase while disabling all checks and enabling the one relevant one. Run on all header files also. 3. Delete .inc files that were also modified, so the next build rebuilds them to a pure state. 4. Some changes have been deleted for the following reasons: - Some files had a variable also named cast - Some files had not included a header file that defines the cast functions - Some files are definitions of the classes that have the casting methods, so the code still refers to the method instead of the function without adding a prefix or removing the method declaration at the same time. ninja -C $BUILD_DIR clang-tidy run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\ -header-filter=mlir/ mlir/* -fix rm -rf $BUILD_DIR/tools/mlir/**/*.inc git restore mlir/lib/IR mlir/lib/Dialect/DLTI/DLTI.cpp\ mlir/lib/Dialect/Complex/IR/ComplexDialect.cpp\ mlir/lib/**/IR/\ mlir/lib/Dialect/SparseTensor/Transforms/SparseVectorization.cpp\ mlir/lib/Dialect/Vector/Transforms/LowerVectorMultiReduction.cpp\ mlir/test/lib/Dialect/Test/TestTypes.cpp\ mlir/test/lib/Dialect/Transform/TestTransformDialectExtension.cpp\ mlir/test/lib/Dialect/Test/TestAttributes.cpp\ mlir/unittests/TableGen/EnumsGenTest.cpp\ mlir/test/python/lib/PythonTestCAPI.cpp\ mlir/include/mlir/IR/ Differential Revision: https://reviews.llvm.org/D150123 | 3 年前 | |
[NFC][Py Reformat] Reformat python files in mlir subdir This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black. If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. If you run into any problems, post to discourse about it and we will try to help. RFC Thread below: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential Revision: https://reviews.llvm.org/D150782 | 3 年前 |