Support standalone builds (work-in-progress) #1245
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
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 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.
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.