llvm
/
torch-mlir
mirror of https://github.com/llvm/torch-mlir
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
torch-mlir/tools/refback-run/CMakeLists.txt

31 lines
718 B
CMake
Raw Normal View History

Rename npcomp-run-mlir to refback-run This better represents its limited scope. This was causing confusion -- people were feeding it higher level ops that require frontend lowering.
2021-08-04 08:53:31 +08:00
# refback-run is always linked dynamically as we want to distribute the
Start reworking towards a shared library build. * Need to have a dag of shared library deps in order to interop across python extensions (as presented in ODM). * Introduced add_npcomp_library and friends to mirror the MLIR setup. * Adds a libNPCOMP.so shared library. * Redirects tools and extensions to link against libNPCOMP.so (instead of static libs). * Moves all libraries to lib/, all binaries to bin/ and all python extensions to python/. The invariant is that the rpaths are setup to have a one level directory structure. * Reworks the _torch_mlir extension to build like the others (still need to come up with a consolidated rule to do this instead of open coded). * Includes an upstream version bump to pick up needed changes. Sizes with dynamic linking (stripped, release, asserts enabled): libNPCOMP.so: 43M (includes much of the underlying LLVM codegen deps) libMLIR.so: 31M _npcomp.so: 1.6M (python extension) _torch_mlir.so: 670K (python extension) npcomp-capi-ir-test: 6.3K npcomp-opt: 351K npcomp-run-mlir: 461K mnist-playground: 530K Still more can be done to normalize and optimize but this gets us structurally to the starting point.
2020-10-09 09:29:59 +08:00
# binaries with the python packages for hacking/debugging.
get_property(dialect_libs GLOBAL PROPERTY NPCOMP_DIALECT_LIBS)
get_property(conversion_libs GLOBAL PROPERTY NPCOMP_CONVERSION_LIBS)
Add bare-bones npcomp-run-mlir. The code isn't super clean, but is a useful incremental step establishing most of the boilerplate for future enhancements. We can't print or return tensors yet so correctness TBD, but I've stepped into the running code in the debugger so I know it definitely is running. This is the first step to building out an npcomp mini-runtime. The mini-runtime doesn't have to be fancy or complex, but it should at least be layered nicely (which this code and the current compiler interaction with the "runtime" code is not). Now that we have boilerplate for e2e execution in some form, we can build that out.
2020-05-29 07:41:36 +08:00
Rename npcomp-run-mlir to refback-run This better represents its limited scope. This was causing confusion -- people were feeding it higher level ops that require frontend lowering.
2021-08-04 08:53:31 +08:00
add_npcomp_executable(refback-run
refback-run.cpp
Add bare-bones npcomp-run-mlir. The code isn't super clean, but is a useful incremental step establishing most of the boilerplate for future enhancements. We can't print or return tensors yet so correctness TBD, but I've stepped into the running code in the debugger so I know it definitely is running. This is the first step to building out an npcomp mini-runtime. The mini-runtime doesn't have to be fancy or complex, but it should at least be layered nicely (which this code and the current compiler interaction with the "runtime" code is not). Now that we have boilerplate for e2e execution in some form, we can build that out.
2020-05-29 07:41:36 +08:00
)
Start reworking towards a shared library build. * Need to have a dag of shared library deps in order to interop across python extensions (as presented in ODM). * Introduced add_npcomp_library and friends to mirror the MLIR setup. * Adds a libNPCOMP.so shared library. * Redirects tools and extensions to link against libNPCOMP.so (instead of static libs). * Moves all libraries to lib/, all binaries to bin/ and all python extensions to python/. The invariant is that the rpaths are setup to have a one level directory structure. * Reworks the _torch_mlir extension to build like the others (still need to come up with a consolidated rule to do this instead of open coded). * Includes an upstream version bump to pick up needed changes. Sizes with dynamic linking (stripped, release, asserts enabled): libNPCOMP.so: 43M (includes much of the underlying LLVM codegen deps) libMLIR.so: 31M _npcomp.so: 1.6M (python extension) _torch_mlir.so: 670K (python extension) npcomp-capi-ir-test: 6.3K npcomp-opt: 351K npcomp-run-mlir: 461K mnist-playground: 530K Still more can be done to normalize and optimize but this gets us structurally to the starting point.
2020-10-09 09:29:59 +08:00
Rename npcomp-run-mlir to refback-run This better represents its limited scope. This was causing confusion -- people were feeding it higher level ops that require frontend lowering.
2021-08-04 08:53:31 +08:00
llvm_update_compile_flags(refback-run)
target_link_libraries(refback-run PRIVATE
Start reworking towards a shared library build. * Need to have a dag of shared library deps in order to interop across python extensions (as presented in ODM). * Introduced add_npcomp_library and friends to mirror the MLIR setup. * Adds a libNPCOMP.so shared library. * Redirects tools and extensions to link against libNPCOMP.so (instead of static libs). * Moves all libraries to lib/, all binaries to bin/ and all python extensions to python/. The invariant is that the rpaths are setup to have a one level directory structure. * Reworks the _torch_mlir extension to build like the others (still need to come up with a consolidated rule to do this instead of open coded). * Includes an upstream version bump to pick up needed changes. Sizes with dynamic linking (stripped, release, asserts enabled): libNPCOMP.so: 43M (includes much of the underlying LLVM codegen deps) libMLIR.so: 31M _npcomp.so: 1.6M (python extension) _torch_mlir.so: 670K (python extension) npcomp-capi-ir-test: 6.3K npcomp-opt: 351K npcomp-run-mlir: 461K mnist-playground: 530K Still more can be done to normalize and optimize but this gets us structurally to the starting point.
2020-10-09 09:29:59 +08:00
NPCOMPCAPI
Rework the python build to a static assembly of MLIR+NPCOMP (#251) * Adapt to python build system updates. * Bump llvm to 310c9496d80961188e8d8f8ad306cdf44bd7541f (includes python build updates) * Adds refback C-API. * Re-layers all python builds. * Rework CI.
2021-07-28 07:10:10 +08:00
NPCOMPInitAll
Add bare-bones npcomp-run-mlir. The code isn't super clean, but is a useful incremental step establishing most of the boilerplate for future enhancements. We can't print or return tensors yet so correctness TBD, but I've stepped into the running code in the debugger so I know it definitely is running. This is the first step to building out an npcomp mini-runtime. The mini-runtime doesn't have to be fancy or complex, but it should at least be layered nicely (which this code and the current compiler interaction with the "runtime" code is not). Now that we have boilerplate for e2e execution in some form, we can build that out.
2020-05-29 07:41:36 +08:00
MLIRAnalysis
MLIRIR
MLIRJitRunner
MLIRParser
MLIRSupport
Make a real library for InitAll and extend it to conditionally initialize dependencies. * Conditioned on the top level CMake option to enable IREE. * There is still some warning flags and such that need triage, but it does build/work.
2020-06-12 08:47:14 +08:00
NPCOMPInitAll
[RefBackend] Move runtime related code under npcomp/RefBackend/ Other than the dialect definitions (which will live in standard Dialect/ subdirectory), the goal here is to keep RefBackend-related code nested in {include/npcomp,lib,test}/RefBackend.
2020-10-08 07:11:41 +08:00
NPCOMPRefBackendJITHelpers
[torch-mlir earthmoving (1/N)] C/C++ code movement. This creates the `external/torch-mlir` directory as an LLVM_EXTERNAL_PROJECTS-compatible project (analogous to `iree-dialects`) and completes movement/rename of all pure MLIR C/C++ compiler code into there. The next step will be to move all the Python code / code that links/includes PyTorch C++ code (which currently lives in `frontends/pytorch`) into a subdirectory here. I call this "earthmoving" because it is mostly mechanical changes and renames. As a quick summary (we can change this down the road easily) - C++ `mlir::NPCOMP::Torch -> mlir::torch::Torch` - CAPI `npcompTorchListTypeGet -> torchMlirTorchListTypeGet` - preprocessor `#ifndef NPCOMP_ -> #ifndef TORCHMLIR_` - CMake `NPCOMPFoo -> TorchMLIRFoo` The goal of this is to create a standalone project creating a center of mass for entry into the MLIR ecosystem from PyTorch, suitable in scope for eventual inclusion/ownership in PyTorch. The idea is that `external/torch-mlir` will some day be pulled out into its own repository, and then npcomp will simply pull it in as a submodule. Layering-wise, what lives in `torch-mlir` lowers code from PyTorch (currently TorchScript, but TorchFX or pytorch/xla-style tracing are possible extensions) down to what we have been calling the "Torch backend contract" which is cleaned up IR (inlining, simplifcation, conversion to value tensors, ...) entirely in the `torch` dialect. This is the branching off point for further lowering, of which npcomp takes one opinion (outside `torch-mlir` of course!), namely the `TorchConversion` dialect/transforms which lower to IR suitable for IREE and other linalg-on-tensors based lower-level compilers. Summary of changes: - move `{include,lib,test}/Dialect/Torch` into `torch-mlir` - move relevant parts of CAPI into `torch-mlir`. - leave a few things related to the `torch-mlir` Python build commented out, which should be resolved in a subsequent change.
2021-09-10 03:24:10 +08:00
TorchMLIRInitAll
Rework the python build to a static assembly of MLIR+NPCOMP (#251) * Adapt to python build system updates. * Bump llvm to 310c9496d80961188e8d8f8ad306cdf44bd7541f (includes python build updates) * Adds refback C-API. * Re-layers all python builds. * Rework CI.
2021-07-28 07:10:10 +08:00
# TODO: Remove these in favor of interface deps.
Misc fixes to enable building/testing on manylinux2014 images. * Since the manylinux images do not hard-link against python libs (resolving them at runtime), the module must be built without resolving undefined references. * For some reason, builds on this platform are stricter, exposing dependency ordering issues. * The CMake bits to build the extension are still somewhat of a mess. I have better versions both upstream and in IREE and will be reconciling. For now, don't look too closely.
2020-08-05 08:10:14 +08:00
${conversion_libs}
${dialect_libs}
Start reworking towards a shared library build. * Need to have a dag of shared library deps in order to interop across python extensions (as presented in ODM). * Introduced add_npcomp_library and friends to mirror the MLIR setup. * Adds a libNPCOMP.so shared library. * Redirects tools and extensions to link against libNPCOMP.so (instead of static libs). * Moves all libraries to lib/, all binaries to bin/ and all python extensions to python/. The invariant is that the rpaths are setup to have a one level directory structure. * Reworks the _torch_mlir extension to build like the others (still need to come up with a consolidated rule to do this instead of open coded). * Includes an upstream version bump to pick up needed changes. Sizes with dynamic linking (stripped, release, asserts enabled): libNPCOMP.so: 43M (includes much of the underlying LLVM codegen deps) libMLIR.so: 31M _npcomp.so: 1.6M (python extension) _torch_mlir.so: 670K (python extension) npcomp-capi-ir-test: 6.3K npcomp-opt: 351K npcomp-run-mlir: 461K mnist-playground: 530K Still more can be done to normalize and optimize but this gets us structurally to the starting point.
2020-10-09 09:29:59 +08:00
)
Rename npcomp-run-mlir to refback-run This better represents its limited scope. This was causing confusion -- people were feeding it higher level ops that require frontend lowering.
2021-08-04 08:53:31 +08:00
add_dependencies(refback-run
Rework e2e flow to use new "npcomprt" This ~totally reworks the existing "runtime" stuff to be more principled and usable, such as from Python. It's still not fully production-quality, mainly in the department of memory management (e.g. it currently leaks memory; we need to figure out "who frees memrefs" + the analysis and transformation needed to do that (maybe use upstream buffer allocation pass?)). The user API is in include/npcomp/runtime/UserAPI.h, though include/npcomp/JITRuntime/JITModule.h is a friendlier wrapper. The stuff under {include,lib}/runtime is totally firewalled from the compiler and tiny (<6kB, though no attention has gone into optimizing that size). For example, we don't link in libSupport into the runtime, instead having our own bare bones replacements for basics like ArrayRef (the JITRuntime helps with bridging that gap, since it *can* depend on all common LLVM utilities). The overall features of npcomprt is that it exposes a module that with multiple function entry points. Each function has arguments and results that are tensor-valued, and npcomprt::Tensor is the runtime type that is used to interact with that (and a npcomprt::Ref<T> reference-counting wrapper is provided to wrap npcomprt::Tensor in the common case). From an implementation perspective, an npcomprt module at the LLVM/object/binary level exposes a single module descriptor struct that has pointers to other metadata (currently just a list of function metadata descriptors). All interactions with the npcomp runtime are keyed off of that module descriptor, including function lookups and dispatching. This is done to dodge platform ABI issues and also allow enough reflection to e.g. verify provided arguments. Most of the compiler-side work here was in LowerToNpcomprtABI and LowerToLLVM. Also, - Rename npcomp_rt/NpcompRt to npcomprt/Npcomprt; it was getting annoying to type the underscores/caps. - misc improvements to bash_helpers.sh
2020-07-09 08:15:40 +08:00
NPCOMPCompilerRuntimeShlib
Add bare-bones npcomp-run-mlir. The code isn't super clean, but is a useful incremental step establishing most of the boilerplate for future enhancements. We can't print or return tensors yet so correctness TBD, but I've stepped into the running code in the debugger so I know it definitely is running. This is the first step to building out an npcomp mini-runtime. The mini-runtime doesn't have to be fancy or complex, but it should at least be layered nicely (which this code and the current compiler interaction with the "runtime" code is not). Now that we have boilerplate for e2e execution in some form, we can build that out.
2020-05-29 07:41:36 +08:00
)