AAlex Zinenko[mlir] Transform op for multitile size generation
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][linalg] Extend opdsl to support operations on complex types. Linalg opdsl now supports negf/add/sub/mul on complex types. Add a test. Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D128010 | 3 年前 | |
[mlir][sparse] Moving integration tests that merely use the Python API Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D114192 | 4 年前 | |
Move MLIR python sources to mlir/python. * NFC but has some fixes for CMake glitches discovered along the way (things not cleaning properly, co-mingled depends). * Includes previously unsubmitted fix in D98681 and a TODO to fix it more appropriately in a smaller followup. Differential Revision: https://reviews.llvm.org/D101493 | 5 年前 | |
[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 年前 | |
[mlir][complex] Add Python bindings for complex ops. Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D127916 | 3 年前 | |
[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 年前 | |
Move MLIR python sources to mlir/python. * NFC but has some fixes for CMake glitches discovered along the way (things not cleaning properly, co-mingled depends). * Includes previously unsubmitted fix in D98681 and a TODO to fix it more appropriately in a smaller followup. Differential Revision: https://reviews.llvm.org/D101493 | 5 年前 | |
[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 年前 | |
[mlir][NFC] Update textual references of func to func.func in examples+python scripts The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][python] Add Python bindings for ml_program dialect. Differential Revision: https://reviews.llvm.org/D125852 | 4 年前 | |
Move MLIR python sources to mlir/python. * NFC but has some fixes for CMake glitches discovered along the way (things not cleaning properly, co-mingled depends). * Includes previously unsubmitted fix in D98681 and a TODO to fix it more appropriately in a smaller followup. Differential Revision: https://reviews.llvm.org/D101493 | 5 年前 | |
[mlir:PDL] Fix a syntax ambiguity in pdl.attribute pdl.attribute currently has a syntax ambiguity that leads to the incorrect parsing of pdl.attribute operations with locations that don't also have a constant value. For example: pdl.attribute loc("foo") The above IR is treated as being a pdl.attribute with a constant value containing the location, loc("foo"), which is incorrect. This commit changes the syntax to use = <constant-value> to clearly distinguish when the constant value is present, as opposed to just trying to parse an attribute. Differential Revision: https://reviews.llvm.org/D124582 | 4 年前 | |
[mlir] Introduce Python bindings for the PDL dialect This change adds full python bindings for PDL, including types and operations with additional mixins to make operation construction more similar to the PDL syntax. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D117458 | 4 年前 | |
[mlir][tblgen][ods][python] Use keyword-only arguments for optional builder arguments in generated Python bindings This diff modifies mlir-tblgen to generate Python Operation class __init__() functions that use Python keyword-only arguments. Previously, all __init__() function arguments were positional. Python code to create MLIR Operations was required to provide values for ALL builder arguments, including optional arguments (attributes and operands). Callers that did not provide, for example, an optional attribute would be forced to provide None as an argument for EACH optional attribute. Proposed changes in this diff use tblgen record information (as provided by ODS) to generate keyword arguments for: - optional operands - optional attributes (which includes unit attributes) - default-valued attributes These __init__() function keyword arguments have default None values (i.e. the argument form is optionalAttr=None), allowing callers to create Operations more easily. Note that since optional arguments become keyword-only arguments (since they are placed after the bare * argument), this diff will require ALL optional operands and attributes to be provided using explicit keyword syntax. This may, in the short term, break any out-of-tree Python code that provided values via positional arguments. However, in the long term, it seems that requiring keywords for optional arguments will be more robust to operation changes that add arguments. Tests were modified to reflect the updated Operation builder calling convention. This diff partially addresses the requests made in the github issue below. https://github.com/llvm/llvm-project/issues/54932 Reviewed By: stellaraccident, mikeurbach Differential Revision: https://reviews.llvm.org/D124717 | 4 年前 | |
[mlir] Introduce Python bindings for the quantization dialect So far, only the custom dialect types are exposed. The build and packaging is same as for Linalg and SparseTensor, and in need of refactoring that is beyond the scope of this patch. Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D116605 | 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 年前 | |
[mlir] Fix build & test of mlir python bindings on Windows There are a couple of issues with the python bindings on Windows: - create_symlink requires special permissions on Windows - using copy_if_different instead allows the build to complete and then be usable - the path to the python_executable is likely to contain spaces if python is installed in Program Files. llvm's python substitution adds extra quotes in order to account for this case, but mlir's own python substitution does not - the location of the shared libraries is different on windows - if the type is not specified for numpy arrays, they appear to be treated as strings I've implemented the smallest possible changes for each of these in the patch, but I would actually prefer a slightly more comprehensive fix for the python_executable and the shared libraries. For the python substitution, I think it makes sense to leverage the existing %python instead of adding %PYTHON and instead add a new variable for the case when preloading is needed. This would also make it clearer which tests are which and should be skipped on platforms where the preloading won't work. For the shared libraries, I think it would make sense to pass the correct path and extension (possibly even the names) to the python script since these are known by lit and don't have to be hardcoded in the test at all. Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D125122 | 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 年前 | |
Enable MLIR Python bindings for TOSA. Differential Revision: https://reviews.llvm.org/D103035 | 5 年前 | |
[mlir] Add ReplicateOp to the Transform dialect This handle manipulation operation allows one to define a new handle that is associated with a the same payload IR operations N times, where N can be driven by the size of payload IR operation list associated with another handle. This can be seen as a sort of broadcast that can be used to ensure the lists associated with two handles have equal numbers of payload IR ops as expected by many pairwise transform operations. Introduce an additional "expensive" check that guards against consuming a handle that is assocaited with the same payload IR operation more than once as this is likely to lead to double-free or other undesired effects. Depends On D129110 Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D129216 | 3 年前 | |
[mlir] Introduce Transform ops for loops Introduce transform ops for "for" loops, in particular for peeling, software pipelining and unrolling, along with a couple of "IR navigation" ops. These ops are intended to be generalized to different kinds of loops when possible and therefore use the "loop" prefix. They currently live in the SCF dialect as there is no clear place to put transform ops that may span across several dialects, this decision is postponed until the ops actually need to handle non-SCF loops. Additionally refactor some common utilities for transform ops into trait or interface methods, and change the loop pipelining to be a returning pattern. Reviewed By: springerm Differential Revision: https://reviews.llvm.org/D127300 | 3 年前 | |
[mlir] Transform op for multitile size generation Introduce a structured transform op that emits IR computing the multi-tile sizes with requested parameters (target size and divisor) for the given structured op. The sizes may fold to arithmetic constant operations when the shape is constant. These operations may then be used to call the existing tiling transformation with a single non-zero dynamic size (i.e. perform strip-mining) for each of the dimensions separately, thus achieving multi-size tiling with optional loop interchange. A separate test exercises the entire script. Depends On D129217 Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D129287 | 3 年前 | |
[mlir][tblgen][ods][python] Use keyword-only arguments for optional builder arguments in generated Python bindings This diff modifies mlir-tblgen to generate Python Operation class __init__() functions that use Python keyword-only arguments. Previously, all __init__() function arguments were positional. Python code to create MLIR Operations was required to provide values for ALL builder arguments, including optional arguments (attributes and operands). Callers that did not provide, for example, an optional attribute would be forced to provide None as an argument for EACH optional attribute. Proposed changes in this diff use tblgen record information (as provided by ODS) to generate keyword arguments for: - optional operands - optional attributes (which includes unit attributes) - default-valued attributes These __init__() function keyword arguments have default None values (i.e. the argument form is optionalAttr=None), allowing callers to create Operations more easily. Note that since optional arguments become keyword-only arguments (since they are placed after the bare * argument), this diff will require ALL optional operands and attributes to be provided using explicit keyword syntax. This may, in the short term, break any out-of-tree Python code that provided values via positional arguments. However, in the long term, it seems that requiring keywords for optional arguments will be more robust to operation changes that add arguments. Tests were modified to reflect the updated Operation builder calling convention. This diff partially addresses the requests made in the github issue below. https://github.com/llvm/llvm-project/issues/54932 Reviewed By: stellaraccident, mikeurbach Differential Revision: https://reviews.llvm.org/D124717 | 4 年前 |