-
Notifications
You must be signed in to change notification settings - Fork 104
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
Support standalone builds (work-in-progress) #1245
base: main
Are you sure you want to change the base?
Conversation
I guess we should rebase ClangIR on top of latest LLVM to have llvm/llvm-project#119408 in it and simplify this PR first? |
fa15e8f
to
154a71a
Compare
I've gotten clang itself working — or at least it seems to compile trivial programs with |
While MLIR currently supports building a libMLIR.so, it does not support actually linking against it for its own tools. When building with LTO, this means we have to relink the world for every tool, and the resulting binaries are large. This adds basic support for MLIR_LINK_MLIR_DYLIB, modelled after how CLANG_LINK_CLANG_DYLIB is implemented: Libraries that are part of libMLIR.so should be added via mlir_target_link_libraries instead of target_link_libraries. This will replace them with libMLIR.so if MLIR_LINK_MLIR_DYLIB is enabled. This adds basic support, I think there are two more things that can be done here: * C API unit tests should link against libMLIR-C.so. Currently these still link statically. * Linking the test libs (not part of libMLIR.so) still pulls in dependencies statically that should come from libMLIR.so.
This commit combines three changes needed for ClangIR to be built successfully on Gentoo with standalone Clang/MLIR install: 1. It unblocks `CLANG_ENABLE_CIR` + `CLANG_BUILT_STANDALONE` scenario, obtaining the necessary bits from system-wide installation of MLIR via `find_package(MLIR)`. 2. It switches linking to MLIR libraries to use `mlir_target_link_libraries()` introduced in 10ef20f6a629797d81252de143117e2a0bc6556d, which supports both linking to invidual MLIR static libraries and to the shared libMLIR library. 3. It makes dependencies on MLIR-specific targets conditional to non-standalone builds -- since these targets aren't present in clang build tree when it is built standalone. These changes do not cover tests yet.
The only change needed was making the dependency on mlir-translate target optional, as mlir-translate is installed as part of mlir when building standalone.
c70cb63
to
9b9353a
Compare
Ok, it turned out easier than I anticipated. I think it's fine to merge it as-is, including the mlir backport, since the next rebase will simply "eat" it, or rebase-then-merge, if you prefer. |
Per llvm/llvm-project#119130. This is incomplete and non-working at this point, but I'd like some early feedback on the approach, especially since it is a bit tedious. I have included llvm/llvm-project#119408 too, since it made linking much easier via
mlir_target_link_libraries
.