Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5 |
|
#
73140dae |
| 17-Apr-2024 |
Oleksandr "Alex" Zinenko <zinenko@google.com> |
[mlir] expose transform dialect symbol merge to python (#87690)
This functionality is available in C++, make it available in Python
directly to operate on transform modules.
|
Revision tags: llvmorg-18.1.4, llvmorg-18.1.3 |
|
#
5a9bdd85 |
| 20-Mar-2024 |
Oleksandr "Alex" Zinenko <zinenko@google.com> |
[mlir] split transform interfaces into a separate library (#85221)
Transform interfaces are implemented, direction or via extensions, in
libraries belonging to multiple other dialects. Those dialec
[mlir] split transform interfaces into a separate library (#85221)
Transform interfaces are implemented, direction or via extensions, in
libraries belonging to multiple other dialects. Those dialects don't
need to depend on the non-interface part of the transform dialect, which
includes the growing number of ops and transitive dependency footprint.
Split out the interfaces into a separate library. This in turn requires
flipping the dependency from the interface on the dialect that has crept
in because both co-existed in one library. The interface shouldn't
depend on the transform dialect either.
As a consequence of splitting, the capability of the interpreter to
automatically walk the payload IR to identify payload ops of a certain
kind based on the type used for the entry point symbol argument is
disabled. This is a good move by itself as it simplifies the interpreter
logic. This functionality can be trivially replaced by a
`transform.structured.match` operation.
show more ...
|
Revision tags: llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4 |
|
#
91f11611 |
| 21-Feb-2024 |
Oleksandr "Alex" Zinenko <zinenko@google.com> |
[mlir] expose transform interpreter to Python (#82365)
Transform interpreter functionality can be used standalone without going
through the interpreter pass, make it available in Python.
|