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

35 lines
637 B
CMake
Raw Normal View History

[onnx] Add torch-mlir-import-onnx native port as an optional tool/library. (#2694) As noted in the plan when this work started, we need to produce an ORT EP plugin for a downstream project, and this will necessitate a C-based ONNX importer (as opposed to the existing Python one). Because this comes with dependencies that we do not want to impart on various projects, this is optional in torch-mlir. It is also factored so that it can be used as standalone sources in downstreams that need it. Since it only depends on public C APIs on the MLIR side, this will make build coupling a lot better (since a C++ dep is not needed on the compiler and it is trivial to dynamically load). Our original plan was just to maintain this fork off to the side in our ORT plugin, but once work started, it seemed better to write it clean and contribute it upstream for anyone to use. We expect that for non-ORT use, the Python importer will have better ergonomics for most folks. I will follow-up with a test suite refactor so that we can drive the Python or C importer. This is a relatively mechanical port from Python to C, borrowing some scaffolding from the old JitIR importer. It does attempt to lay some groundwork for external data, which will need to be implemented on the Python side as well.
2023-12-28 04:13:34 +08:00
message(STATUS "Enabling onnx_c_importer...")
include(FetchContent)
build: find Protobuf using config mode search (#2900) This patch makes the Protobuf package mandatory in addition to forcing a config mode search. The (default) module mode search looks for the CMake-provided FindProtobuf.cmake file, but this file does not list Abseil as a dependency, causing linker issues like the one below: ``` ld: Undefined symbols: absl::lts_20230802::log_internal::LogMessageFatal::LogMessageFatal(char const*, int, std::__1::basic_string_view<char, std::__1::char_traits<char>>), referenced from: google::protobuf::RepeatedPtrField<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>::TypeHandler::Type const& google::protobuf::internal::RepeatedPtrFieldBase::Get<google::protobuf::RepeatedPtrField<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>::TypeHandler>(int) const (.cold.1) in OnnxImporter.cpp.o ``` By forcing a config mode search, CMake looks for the file that is installed as part of the protobuf package and which does contain the Abseil dependency. This workaround is also mentioned in a GitHub issue for Protobuf: https://github.com/protocolbuffers/protobuf/issues/12292#issuecomment-1529680040.
2024-02-13 07:31:41 +08:00
find_package(Protobuf REQUIRED CONFIG)
[onnx] Add torch-mlir-import-onnx native port as an optional tool/library. (#2694) As noted in the plan when this work started, we need to produce an ORT EP plugin for a downstream project, and this will necessitate a C-based ONNX importer (as opposed to the existing Python one). Because this comes with dependencies that we do not want to impart on various projects, this is optional in torch-mlir. It is also factored so that it can be used as standalone sources in downstreams that need it. Since it only depends on public C APIs on the MLIR side, this will make build coupling a lot better (since a C++ dep is not needed on the compiler and it is trivial to dynamically load). Our original plan was just to maintain this fork off to the side in our ORT plugin, but once work started, it seemed better to write it clean and contribute it upstream for anyone to use. We expect that for non-ORT use, the Python importer will have better ergonomics for most folks. I will follow-up with a test suite refactor so that we can drive the Python or C importer. This is a relatively mechanical port from Python to C, borrowing some scaffolding from the old JitIR importer. It does attempt to lay some groundwork for external data, which will need to be implemented on the Python side as well.
2023-12-28 04:13:34 +08:00
option(ONNX_DISABLE_EXCEPTIONS "For compatibility with LLVM build" ON)
FetchContent_Declare(
onnx
EXCLUDE_FROM_ALL
GIT_REPOSITORY https://github.com/onnx/onnx.git
GIT_TAG v1.15.0
GIT_SHALLOW ON
GIT_PROGRESS ON
)
FetchContent_MakeAvailable(onnx)
add_llvm_executable(
torch-mlir-import-onnx
PARTIAL_SOURCES_INTENDED
import-onnx-main.cpp
OnnxImporter.h
OnnxImporter.cpp
)
target_link_libraries(
torch-mlir-import-onnx
LLVMSupport
MLIRCAPIIR
TorchMLIRCAPI
onnx
)