Support standalone builds (work-in-progress) #1245
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? |
mgorny
force-pushed
the
cir-standalone
branch
3 times, most recently
from
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 10ef20f, 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.
mgorny
force-pushed
the
cir-standalone
branch
from
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. |
|
With the invocation: on Linux-x86_64 I end up with The LLVM build does include MLIR. Is this the right standalone invocation? |
|
It's a 3-step "total standalone":
|
|
I mean, I suppose it will also work if you include MLIR in your LLVM build, i.e. |
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.