-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[libc] Only enable LLVM_FULL_BUILD_MODE
by default for GPU targets
#84664
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
Merged
Conversation
This file contains hidden or 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
Summary: Currently we have a conditional that turns the full build on by default if it is a default target. This used to work fine when the GPU was the only target that was ever present. However, we've recently changed to allow building multiple of these at the same time. That means we should have the ability to build overlay mode in the CPU mode and full build in the GPU mode. This patch makes some simple adjustments to pass the arguments per-triple. This slightly extends the existing `-DRUNTIMES_` argument support to also transform any extra CMake inputs rather than just the passed CMake variables.
jhuber6
added a commit
to jhuber6/llvm-project
that referenced
this pull request
Mar 10, 2024
Summary: The libc build has a few utilties that need to be built before we can do everything in the full build. The one requirement currently is the `libc-hdrgen` binary. If we are doing a full build runtimes mode we first add `libc` to the projects list and then only use the `projects` portion to buld the `libc` portion. We also use utilities for the GPU build, namely the loader utilities. Previously we would build these tools on-demand inside of the cross-build, which tool some hacky workarounds for the dependency finding and target triple. This patch instead just builds them similarly to libc-hdrgen and then passses them in. We now either pass it manually it it was built, or just look it up like we do with the other `clang` tools. Depends on llvm#84664
jhuber6
added a commit
to jhuber6/llvm-project
that referenced
this pull request
Mar 10, 2024
Summary: The libc build has a few utilties that need to be built before we can do everything in the full build. The one requirement currently is the `libc-hdrgen` binary. If we are doing a full build runtimes mode we first add `libc` to the projects list and then only use the `projects` portion to buld the `libc` portion. We also use utilities for the GPU build, namely the loader utilities. Previously we would build these tools on-demand inside of the cross-build, which tool some hacky workarounds for the dependency finding and target triple. This patch instead just builds them similarly to libc-hdrgen and then passses them in. We now either pass it manually it it was built, or just look it up like we do with the other `clang` tools. Depends on llvm#84664
jhuber6
added a commit
to jhuber6/llvm-project
that referenced
this pull request
Mar 10, 2024
Summary: The libc build has a few utilties that need to be built before we can do everything in the full build. The one requirement currently is the `libc-hdrgen` binary. If we are doing a full build runtimes mode we first add `libc` to the projects list and then only use the `projects` portion to buld the `libc` portion. We also use utilities for the GPU build, namely the loader utilities. Previously we would build these tools on-demand inside of the cross-build, which tool some hacky workarounds for the dependency finding and target triple. This patch instead just builds them similarly to libc-hdrgen and then passses them in. We now either pass it manually it it was built, or just look it up like we do with the other `clang` tools. Depends on llvm#84664
jhuber6
added a commit
to jhuber6/llvm-project
that referenced
this pull request
Mar 10, 2024
Summary: The libc build has a few utilties that need to be built before we can do everything in the full build. The one requirement currently is the `libc-hdrgen` binary. If we are doing a full build runtimes mode we first add `libc` to the projects list and then only use the `projects` portion to buld the `libc` portion. We also use utilities for the GPU build, namely the loader utilities. Previously we would build these tools on-demand inside of the cross-build, which tool some hacky workarounds for the dependency finding and target triple. This patch instead just builds them similarly to libc-hdrgen and then passses them in. We now either pass it manually it it was built, or just look it up like we do with the other `clang` tools. Depends on llvm#84664
lntue
approved these changes
Mar 11, 2024
jhuber6
added a commit
to jhuber6/llvm-project
that referenced
this pull request
Mar 11, 2024
Summary: The libc build has a few utilties that need to be built before we can do everything in the full build. The one requirement currently is the `libc-hdrgen` binary. If we are doing a full build runtimes mode we first add `libc` to the projects list and then only use the `projects` portion to buld the `libc` portion. We also use utilities for the GPU build, namely the loader utilities. Previously we would build these tools on-demand inside of the cross-build, which tool some hacky workarounds for the dependency finding and target triple. This patch instead just builds them similarly to libc-hdrgen and then passses them in. We now either pass it manually it it was built, or just look it up like we do with the other `clang` tools. Depends on llvm#84664
jhuber6
added a commit
that referenced
this pull request
Mar 11, 2024
Summary: The libc build has a few utilties that need to be built before we can do everything in the full build. The one requirement currently is the `libc-hdrgen` binary. If we are doing a full build runtimes mode we first add `libc` to the projects list and then only use the `projects` portion to buld the `libc` portion. We also use utilities for the GPU build, namely the loader utilities. Previously we would build these tools on-demand inside of the cross-build, which tool some hacky workarounds for the dependency finding and target triple. This patch instead just builds them similarly to libc-hdrgen and then passses them in. We now either pass it manually it it was built, or just look it up like we do with the other `clang` tools. Depends on #84664
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.
Summary:
Currently we have a conditional that turns the full build on by default
if it is a default target. This used to work fine when the GPU was the
only target that was ever present. However, we've recently changed to
allow building multiple of these at the same time. That means we should
have the ability to build overlay mode in the CPU mode and full build in
the GPU mode. This patch makes some simple adjustments to pass the
arguments per-triple. This slightly extends the existing
-DRUNTIMES_
argument support to also transform any extra CMake inputs rather than
just the passed CMake variables.