Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for building CompilerGym using CMake #506

Closed
1 of 7 tasks
ChrisCummins opened this issue Dec 9, 2021 · 11 comments
Closed
1 of 7 tasks

Add support for building CompilerGym using CMake #506

ChrisCummins opened this issue Dec 9, 2021 · 11 comments
Assignees
Labels
Enhancement New feature or request Testing & Tooling Tests, tooling, and build systems
Milestone

Comments

@ChrisCummins
Copy link
Contributor

ChrisCummins commented Dec 9, 2021

🚀 Feature

This is a tracking issue for the progress that @KyleHerndon and @sogartar have made on adding support for building CompilerGym using CMake.

The initial discussions and plan were outlined in the comments of this PR #478.

Progress:

  • Support for building the CompilerGym wheel on Linux (Add Building with CMake #498)
  • Support for building the CompilerGym wheel on macOS
  • Support for building examples/
  • Support for building benchmarks/
  • Resolve the TODO(github.com/facebookresearch/CompilerGym/issues/506) issues in the source.
  • Speed up the build, especially the CI job (Speedup CMake Configuration #595)
  • Rewrite the CMakeLists files to use more idiomatic CMake style
@ChrisCummins
Copy link
Contributor Author

General question for @sogartar and @KyleHerndon, is it on your roadmap to add macOS support to the CMake build?

Cheers,
Chris

@sogartar
Copy link

General question for @sogartar and @KyleHerndon, is it on your roadmap to add macOS support to the CMake build?

@ChrisCummins, we are planing to add it after we add the MLIR env. So it will be in a few weeks.
There is also the examples and benchmarks that are not yet buildable with CMake that we have to address.

@ChrisCummins
Copy link
Contributor Author

Awesome, thanks! I'll add a progress list to this task. I don't think the examples or benchmarks directories will be too challenging as they don't have a lot of compiled code

Cheers,
Chris

@ChrisCummins
Copy link
Contributor Author

@sogartar, is it possible to configure the CMake build to use a local copy of LLVM? Let's say I have a fork of LLVM and have arranged it with the following directory:

~/llvm/build  # cmake build dir
~/llvm/src  # sources
~/llvm/install  # install target
~/CompilerGym  # CompilerGym

From looking through the CMake configs it looks like the only control I have over the LLVM version used is -DCOMPILER_GYM_LLVM_PROVIDER=external, though even then it downloads and uses the v10.0.0 sources, and I'm not sure how it locates the binaries / libs. Sorry for the n00by CMake questions, I'm still getting up to speed with it :-)

Cheers,
Chris

@ChrisCummins
Copy link
Contributor Author

ChrisCummins commented Feb 8, 2022

The use cases I would like to support with this are:

  • The user has a local fork of LLVM that they want to build the CompilerGym environment against. The user should be able to pass the path of their local source and install directories and CompilerGym will build against it.
  • The user wants to download and build against LLVM's binary and source release archives. This is equivalent to how the Bazel build works, and would enable the user to build CompilerGym without having to compile LLVM from scratch (this could be the default for CI jobs to make the CMake build the default).
  • The user wants the CompilerGym to build LLVM from source (as is the default now), but using a different version of LLVM, and controlling some of the LLVM build options. E.g. cmake ... -DLLVM_SRCS=https://github.com/llvm/llvm-project/archive/refs/tags/llvmorg-12.0.1.tar.gz -DCMAKE_BUILD_TYPE=Release.

I'm happy to help contribute towards this if you give me a couple of pointers on how to start.

@sogartar
Copy link

sogartar commented Feb 8, 2022

The DCOMPILER_GYM_LLVM_PROVIDER=external option is not tested yet, but it is supposed to only find a preinstalled LLVM without building it. If it is not installed in a default location like /usr/local then the path should be provided according to the specifics of find_package(...) for LLVM. Usually you can do that by specifying CMAKE_PREFIX_PATH or PackageName_DIR for a specific package. For example LLVM_DIR.

cmake -D LLVM_DIR=/path/to/llvm/install ...

Some packages provide custom find_package logic that may have other ways of customizing the search paths, but usually they try to stick to these variables.

Currently there is no way to specify an external LLVM source to be included in the super-build. I see now that this may be a problem, since we need the LLVM source code also during the build, which may crate a mismatch of versions. This piece would need refactoring.

@ChrisCummins
Copy link
Contributor Author

ChrisCummins commented Feb 10, 2022

The DCOMPILER_GYM_LLVM_PROVIDER=external option is not tested yet, but it is supposed to only find a preinstalled LLVM without building it. If it is not installed in a default location like /usr/local then the path should be provided according to the specifics of [find_package(...)](https://cmake.org/cmake/help/latest/command/find_package.html) for LLVM. Usually you can do that by specifying CMAKE_PREFIX_PATH or _DIR for a specific package. For example LLVM_DIR.

cmake -D LLVM_DIR=/path/to/llvm/install ...

Some packages provide custom find_package logic that may have other ways of customizing the search paths, but usually they try to stick to these variables.

Thanks for the details. I have tried:

$ cmake ... -DCOMPILER_GYM_LLVM_PROVIDER=external -DLLVM_DIR=/path/to/my/llvm

But I found that LLVM_DIR was still set to build/external/.... I'll dig into this a bit and let you know what I find.

Currently there is no way to specify an external LLVM source to be included in the super-build. I see now that this may be a problem, since we need the LLVM source code also during the build, which may crate a mismatch of versions. This piece would need refactoring.

The LLVM sources are only needed by the scripts in this dir to extract the list of passes and generate a couple of .h/.py files. One workaround could be to split this out from the regular build by committing the generated files for whatever version of LLVM we build against. That way we don't need the LLVM sources, and users could run these scripts to generate their own files against a different version of LLVM should they wish (cf #568).

Cheers,
Chris

@sogartar
Copy link

Thanks for the details. I have tried:

$ cmake ... -DCOMPILER_GYM_LLVM_PROVIDER=external -DLLVM_DIR=/path/to/my/llvm

But I found that LLVM_DIR was still set to build/external/.... I'll dig into this a bit and let you know what I find.

There may be some other problem but according to https://llvm.org/docs/CMake.html LLVM_DIR is the variable to use.

@sogartar
Copy link

In build_external_cmake_project the install dir is added to CMAKE_PREFIX_PATH. Although I doubt it, but it may take precedence over LLVM_DIR.

@ChrisCummins
Copy link
Contributor Author

Thanks. I was able to fix this by replacing this with just:

find_package(LLVM REQUIRED CONFIG)

I'm working on a conditional if/else block depending on COMPILER_GYM_LLVM_PROVIDER like here but am still figuring out how cmake works :) There are some other issues like conflicting gtest definitions.

Cheers,
Chris

@ChrisCummins
Copy link
Contributor Author

@sogartar, @kylescotshank, @mostafaelhoushi, I've created a new project to track the various tasks needed to fully migrate from Bazel to CMake. I'll split the list of tasks here into individual issues that can be tracked and discussed separately.

Closing this in favor of tracking progress on the project page.

Cheers,
Chris

@ChrisCummins ChrisCummins self-assigned this Nov 29, 2022
@ChrisCummins ChrisCummins added this to the v0.3.0 milestone Apr 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New feature or request Testing & Tooling Tests, tooling, and build systems
Projects
None yet
Development

No branches or pull requests

2 participants