search

iree-org / iree

A retargetable MLIR-based machine learning compiler and runtime toolkit.
http://iree.dev/
Apache License 2.0
2.75k stars 599 forks source link

Implement vcpkg for the IREE runtime #15549

Open saienduri opened 11 months ago

saienduri commented 11 months ago

Request description

This feature would be getting us a supported out of tree sample user of the C runtime. The motivation here is to provide any user with an advertised/supported/tested flow to be able to depend on the runtime. After this feature is implemented, IREE will have a front door that works for taking a direct CMake dep and a vcpkg port.

My plan to implement this consists of 2 major steps. The goal is to be able to use iree runtime like sqllite3 is used in this link: https://learn.microsoft.com/en-us/vcpkg/examples/installing-and-using-packages.

First Step: Packaging iree and adding port

In this step, I will be doing something like this to package the iree github repo: https://learn.microsoft.com/en-us/vcpkg/examples/packaging-github-repos. The main thing here is that we can configure vcpkg_cmake_configure and vcpkg_cmake_install, so that we are only building the runtime. I will set the options similar to the cmake options in this file: https://github.com/iree-org/iree-template-runtime-cmake/blob/main/CMakeLists.txt in the IREE subproject configuration section. Now, that a user will be able to install the runtime, we can move onto the next step of providing them with a template.

Second Step: creating template repository that uses the iree port install

In this repository, we will have a CMakeLists.txt file similar to this:

# CMakeLists.txt
cmake_minimum_required(VERSION 3.21...3.24)
project(iree-template-runtime-vcpkg)

find_package(iree-runtime)

add_executable(hello hello.c)

#do I have to do something else to be able to access IREE_DEFAULT_COPTS?
target_compile_options(${_NAME} PRIVATE ${IREE_DEFAULT_COPTS})

target_link_libraries(main PRIVATE unofficial::iree-runtime)

We will also have the c file as a part of this repository (hello_world.c in the template). This will have the two includes, which should be taken care of with our target_link_libraries:

include

// When using the ireeruntime* APIs this is the only include required:

include <iree/runtime/api.h>

Then, we should be able to proceed with building this repo normally. cmake "-DCMAKE_TOOLCHAIN_FILE=D:\src\vcpkg\scripts\buildsystems\vcpkg.cmake" (configuring step for vcpkg) cmake -B build/ -GNinja . cmake --build build/ --target hello_world

What component(s) does this issue relate to?

No response

Additional context

No response

ScottTodd commented 11 months ago

I will set the options similar to the cmake options in this file: https://github.com/iree-org/iree-template-runtime-cmake/blob/main/CMakeLists.txt in the IREE subproject configuration section.

One thing that stands out to me in there is this:

set(IREE_HAL_DRIVER_DEFAULTS OFF)
set(IREE_HAL_DRIVER_LOCAL_SYNC ON)
set(IREE_HAL_EXECUTABLE_LOADER_DEFAULTS OFF)
set(IREE_HAL_EXECUTABLE_LOADER_EMBEDDED_ELF ON)

I'd start with something minimal like that and then in the future add "feature packages" and other variants (Android?), as in https://learn.microsoft.com/en-us/vcpkg/users/examples/selecting-llvm-features. For example, we may want to include the Metal HAL driver on macOS but not Windows or Linux.

Regarding this:

#do I have to do something else to be able to access IREE_DEFAULT_COPTS?
target_compile_options(${_NAME} PRIVATE ${IREE_DEFAULT_COPTS})

Maybe. That option is kind of weird anyways - we shouldn't be forcing options on downstream users. If the runtime code ends up being built into a .dll/.so separately from the user application code then that should establish a boundary where compiler warnings and other flags can drift a bit.

I'm also expecting the packaging to pull all git submodules and source files, which can be slow (~10-15 minutes depending on network and file I/O) considering how large LLVM is. We'll likely just ignore that for some time, but in the future we could set up a iree-runtime GitHub repository that is much faster to clone.

stellaraccident commented 11 months ago

fyi - if it all comes together right, you shouldn't need this: "target_compile_options(${_NAME} PRIVATE ${IREE_DEFAULT_COPTS})"

stellaraccident commented 11 months ago

I think I found something online on how to selectively pull submodules. Can't remember where... it was from the time before submodules were supported by vcpkg at all (2019?) and was just the way you could make it work.

ScottTodd commented 11 months ago

I think I found something online on how to selectively pull submodules. Can't remember where... it was from the time before submodules were supported by vcpkg at all (2019?) and was just the way you could make it work.

We have this in the template instructions:

$ git \
    -c submodule."third_party/llvm-project".update=none \
    -c submodule."third_party/stablehlo".update=none \
    -c submodule."third_party/torch-mlir".update=none \
    submodule update --init --recursive

And in-tree build_tools/scripts/git/update_runtime_submodules.sh + build_tools/scripts/git/runtime_submodules.txt

I assume that anything built on top of git (pip, vcpkg, etc.) treats submodules as all-or-nothing though.

saienduri commented 11 months ago

Cool cool, thanks for the feedback! I will see if we can do some sort of selective submodule selection to shorten the installation.

marbre commented 11 months ago

In iree-bare-metal-arm, we set IREE_ERROR_ON_MISSING_SUBMODULESto OFF (see here which allows us to only clone a part of the submodules and to skip a recursive initalization of the submodules (see here) when cross-compiling the runtime. This was introduced with https://github.com/openxla/iree/commit/776d7e6072fd7ca42cab03fd68e9a04f5aeacebb and should allow further changes like https://github.com/openxla/iree/commit/9b86ad5f69e85ff77c4575283f6807259fc0ab0b.