Commit Graph

4 Commits

Author SHA1 Message Date
Stella Laurenzo 5b2e7f50a6 [MLIR][python] Export CAPI headers.
* Adds source targets (not included in the full set that downstreams use by default) to bundle mlir-c/ headers into the mlir/_mlir_libs/include directory.
* Adds a minimal entry point to get include and library directories.
* Used by npcomp to export a full CAPI (which is then used by the Torch extension to link npcomp).

Reviewed By: mikeurbach

Differential Revision: https://reviews.llvm.org/D107090
2021-07-29 19:06:32 +00:00
Stella Laurenzo 0cdf491501 Break apart the MLIR ExecutionEngine from core python module.
* For python projects that don't need JIT/ExecutionEngine, cuts the number of files to compile roughly in half (with similar reduction in end binary size).

Differential Revision: https://reviews.llvm.org/D106992
2021-07-28 23:59:32 +00:00
Stella Laurenzo 310c9496d8 Re-engineer MLIR python build support.
* Implements all of the discussed features:
  - Links against common CAPI libraries that are self contained.
  - Stops using the 'python/' directory at the root for everything, opening the namespace up for multiple projects to embed the MLIR python API.
  - Separates declaration of sources (py and C++) needed to build the extension from building, allowing external projects to build custom assemblies from core parts of the API.
  - Makes the core python API relocatable (i.e. it could be embedded as something like 'npcomp.ir', 'npcomp.dialects', etc). Still a bit more to do to make it truly isolated but the main structural reset is done.
  - When building statically, installed python packages are completely self contained, suitable for direct setup and upload to PyPi, et al.
  - Lets external projects assemble their own CAPI common runtime library that all extensions use. No more possibilities for TypeID issues.
  - Begins modularizing the API so that external projects that just include a piece pay only for what they use.
* I also rolled in a re-organization of the native libraries that matches how I was packaging these out of tree and is a better layering (i.e. all libraries go into a nested _mlir_libs package). There is some further cleanup that I resisted since it would have required source changes that I'd rather do in a followup once everything stabilizes.
* Note that I made a somewhat odd choice in choosing to recompile all extensions for each project they are included into (as opposed to compiling once and just linking). While not leveraged yet, this will let us set definitions controlling the namespacing of the extensions so that they can be made to not conflict across projects (with preprocessor definitions).
* This will be a relatively substantial breaking change for downstreams. I will handle the npcomp migration and will coordinate with the circt folks before landing. We should stage this and make sure it isn't causing problems before landing.
* Fixed a couple of absolute imports that were causing issues.

Differential Revision: https://reviews.llvm.org/D106520
2021-07-27 15:54:58 +00:00
Stella Laurenzo 9f3f6d7bd8 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
2021-05-03 18:36:48 +00:00