Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3 |
|
#
d1fdb416 |
| 08-Feb-2024 |
John Demme <john.demme@microsoft.com> |
[MLIR][Python] Add method for getting the live operation objects (#78663)
Currently, a method exists to get the count of the operation objects
which are still alive. This helps for sanity checking,
[MLIR][Python] Add method for getting the live operation objects (#78663)
Currently, a method exists to get the count of the operation objects
which are still alive. This helps for sanity checking, but isn't
terribly useful for debugging. This new method returns the actual
operation objects which are still alive.
This allows Python code like the following:
```
gc.collect()
live_ops = ir.Context.current._get_live_operation_objects()
for op in live_ops:
print(f"Warning: {op} is still live. Referrers:")
for referrer in gc.get_referrers(op)[0]:
print(f" {referrer}")
```
show more ...
|
Revision tags: llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5 |
|
#
f9008e63 |
| 17-May-2023 |
Tobias Hieta <tobias@hieta.se> |
[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
[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
show more ...
|
Revision tags: llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2 |
|
#
3ea4c501 |
| 07-Feb-2023 |
Rahul Kayaith <rkayaith@gmail.com> |
[mlir][python] Capture error diagnostics in exceptions
This updates most (all?) error-diagnostic-emitting python APIs to capture error diagnostics and include them in the raised exception's message:
[mlir][python] Capture error diagnostics in exceptions
This updates most (all?) error-diagnostic-emitting python APIs to capture error diagnostics and include them in the raised exception's message: ``` >>> Operation.parse('"arith.addi"() : () -> ()')) Traceback (most recent call last): File "<stdin>", line 1, in <module> mlir._mlir_libs.MLIRError: Unable to parse operation assembly: error: "-":1:1: 'arith.addi' op requires one result note: "-":1:1: see current operation: "arith.addi"() : () -> () ```
The diagnostic information is available on the exception for users who may want to customize the error message: ``` >>> try: ... Operation.parse('"arith.addi"() : () -> ()') ... except MLIRError as e: ... print(e.message) ... print(e.error_diagnostics) ... print(e.error_diagnostics[0].message) ... Unable to parse operation assembly [<mlir._mlir_libs._mlir.ir.DiagnosticInfo object at 0x7fed32bd6b70>] 'arith.addi' op requires one result ```
Error diagnostics captured in exceptions aren't propagated to diagnostic handlers, to avoid double-reporting of errors. The context-level `emit_error_diagnostics` option can be used to revert to the old behaviour, causing error diagnostics to be reported to handlers instead of as part of exceptions.
API changes: - `Operation.verify` now raises an exception on verification failure, instead of returning `false` - The exception raised by the following methods has been changed to `MLIRError`: - `PassManager.run` - `{Module,Operation,Type,Attribute}.parse` - `{RankedTensorType,UnrankedTensorType}.get` - `{MemRefType,UnrankedMemRefType}.get` - `VectorType.get` - `FloatAttr.get`
closes #60595
depends on D144804, D143830
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D143869
show more ...
|
Revision tags: llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2 |
|
#
2310ced8 |
| 20-Apr-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir][NFC] Update textual references of `func` to `func.func` in examples+python scripts
The special case parsing of `func` operations is being removed.
|
#
6b0bed7e |
| 19-Apr-2022 |
John Demme <john.demme@microsoft.com> |
[MLIR] [Python] Add a method to clear live operations map
Introduce a method on PyMlirContext (and plumb it through to Python) to invalidate all of the operations in the live operations map and clea
[MLIR] [Python] Add a method to clear live operations map
Introduce a method on PyMlirContext (and plumb it through to Python) to invalidate all of the operations in the live operations map and clear it. Since Python has no notion of private data, an end-developer could reach into some 3rd party API which uses the MLIR Python API (that is behaving correctly with regard to holding references) and grab a reference to an MLIR Python Operation, preventing it from being deconstructed out of the live operations map. This allows the API developer to clear the map when it calls C++ code which could delete operations, protecting itself from its users.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D123895
show more ...
|
Revision tags: llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
#
ace1d0ad |
| 28-Nov-2021 |
Stella Laurenzo <stellaraccident@gmail.com> |
[mlir][python] Normalize asm-printing IR behavior.
While working on an integration, I found a lot of inconsistencies on IR printing and verification. It turns out that we were: * Only doing "soft
[mlir][python] Normalize asm-printing IR behavior.
While working on an integration, I found a lot of inconsistencies on IR printing and verification. It turns out that we were: * Only doing "soft fail" verification on IR printing of Operation, not of a Module. * Failed verification was interacting badly with binary=True IR printing (causing a TypeError trying to pass an `str` to a `bytes` based handle). * For systematic integrations, it is often desirable to control verification yourself so that you can explicitly handle errors.
This patch: * Trues up the "soft fail" semantics by having `Module.__str__` delegate to `Operation.__str__` vs having a shortcut implementation. * Fixes soft fail in the presence of binary=True (and adds an additional happy path test case to make sure the binary functionality works). * Adds an `assume_verified` boolean flag to the `print`/`get_asm` methods which disables internal verification, presupposing that the caller has taken care of it.
It turns out that we had a number of tests which were generating illegal IR but it wasn't being caught because they were doing a print on the `Module` vs operation. All except two were trivially fixed: * linalg/ops.py : Had two tests for direct constructing a Matmul incorrectly. Fixing them made them just like the next two tests so just deleted (no need to test the verifier only at this level). * linalg/opdsl/emit_structured_generic.py : Hand coded conv and pooling tests appear to be using illegal shaped inputs/outputs, causing a verification failure. I just used the `assume_verified=` flag to restore the original behavior and left a TODO. Will get someone who owns that to fix it properly in a followup (would also be nice to break this file up into multiple test modules as it is hard to tell exactly what is failing).
Notes to downstreams: * If, like some of our tests, you get verification failures after this patch, it is likely that your IR was always invalid and you will need to fix the root cause. To temporarily revert to prior (broken) behavior, replace calls like `print(module)` with `print(module.operation.get_asm(assume_verified=True))`.
Differential Revision: https://reviews.llvm.org/D114680
show more ...
|
Revision tags: llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
#
9f3f6d7b |
| 28-Apr-2021 |
Stella Laurenzo <stellaraccident@gmail.com> |
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 fi
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
show more ...
|