[LLVM] Add LLVM_<proj>_RUNTIME_TARGETS to set targets per-project
#81557
Conversation
|
You can already do the following: This is already used in existing builds. Is that sufficient for your use case? |
Will that allow the other targets to still be built? For example, like in the main comment where I have |
jhuber6
force-pushed
the
RuntimesOverload
branch
from
562c3aa to
48e738f
Compare
|
So, I tired it out and it doesn't seem to have the semantics that I need. I want to be able to specify that only a specific project is built with the desired architecture, that means omitting it from the standard targets if present. That doesn't happen with the above |
|
I'm not sure I follow, why are other runtimes like The reason I'm not a fan of the proposed solution is that it seems to be specifically tailored to libc and I'm worried that it won't generalize. Specifically, runtimes are typically layered on top of each other, that is In your description, you also mentioned |
What I meant is that it required passing And the issue was that it was still building
That's easily doable if the user manually configures the override to include either I think the semantics there are straightforward enogh.
That's a typo, I meant |
|
Also, like you said, this might not be explicitly useful beyond |
|
Would it be possible to make this move along faster if I just implemented it as |
Summary: This is a massive patch because it reworks the entire build and everything that depends on it. This is not split up because various bots would fail otherwise. I will attempt to describe the necessary changes here. This patch completely reworks how the GPU build is built and targeted. Previously, we used a standard runtimes build and handled both NVPTX and AMDGPU in a single build via multi-targeting. This added a lot of divergence in the build system and prevented us from doing various things like building for the CPU / GPU at the same time, or exporting the startup libraries or running tests without a full rebuild. The new appraoch is to handle the GPU builds as strict cross-compiling runtimes. The first step required llvm#81557 to allow the `LIBC` target to build for the GPU without touching the other targets. This means that the GPU uses all the same handling as the other builds in `libc`. The new expected way to build the GPU libc is with `LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`. The second step was reworking how we generated the embedded GPU library by moving it into the library install step. Where we previously had one `libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This patch includes the necessary clang / OpenMP changes to make that not break the bots when this lands. We unfortunately still require that the NVPTX target has an `internal` target for tests. This is because the NVPTX target needs to do LTO for the provided version (The offloading toolchain can handle it) but cannot use it for the native toolchain which is used for making tests. This approach is vastly suprerior in every way, allowing us to treat the GPU as a standard cross-compiling target. We can now install the GPU utilities to do things like use the offload tests and other fun things. Depends on llvm#81557
|
Also @petrhosek, I've noticed that the non-default targets don't use |
Summary: This is a massive patch because it reworks the entire build and everything that depends on it. This is not split up because various bots would fail otherwise. I will attempt to describe the necessary changes here. This patch completely reworks how the GPU build is built and targeted. Previously, we used a standard runtimes build and handled both NVPTX and AMDGPU in a single build via multi-targeting. This added a lot of divergence in the build system and prevented us from doing various things like building for the CPU / GPU at the same time, or exporting the startup libraries or running tests without a full rebuild. The new appraoch is to handle the GPU builds as strict cross-compiling runtimes. The first step required llvm#81557 to allow the `LIBC` target to build for the GPU without touching the other targets. This means that the GPU uses all the same handling as the other builds in `libc`. The new expected way to build the GPU libc is with `LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`. The second step was reworking how we generated the embedded GPU library by moving it into the library install step. Where we previously had one `libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This patch includes the necessary clang / OpenMP changes to make that not break the bots when this lands. We unfortunately still require that the NVPTX target has an `internal` target for tests. This is because the NVPTX target needs to do LTO for the provided version (The offloading toolchain can handle it) but cannot use it for the native toolchain which is used for making tests. This approach is vastly suprerior in every way, allowing us to treat the GPU as a standard cross-compiling target. We can now install the GPU utilities to do things like use the offload tests and other fun things. Depends on llvm#81557
Summary: This is a massive patch because it reworks the entire build and everything that depends on it. This is not split up because various bots would fail otherwise. I will attempt to describe the necessary changes here. This patch completely reworks how the GPU build is built and targeted. Previously, we used a standard runtimes build and handled both NVPTX and AMDGPU in a single build via multi-targeting. This added a lot of divergence in the build system and prevented us from doing various things like building for the CPU / GPU at the same time, or exporting the startup libraries or running tests without a full rebuild. The new appraoch is to handle the GPU builds as strict cross-compiling runtimes. The first step required llvm#81557 to allow the `LIBC` target to build for the GPU without touching the other targets. This means that the GPU uses all the same handling as the other builds in `libc`. The new expected way to build the GPU libc is with `LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`. The second step was reworking how we generated the embedded GPU library by moving it into the library install step. Where we previously had one `libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This patch includes the necessary clang / OpenMP changes to make that not break the bots when this lands. We unfortunately still require that the NVPTX target has an `internal` target for tests. This is because the NVPTX target needs to do LTO for the provided version (The offloading toolchain can handle it) but cannot use it for the native toolchain which is used for making tests. This approach is vastly suprerior in every way, allowing us to treat the GPU as a standard cross-compiling target. We can now install the GPU utilities to do things like use the offload tests and other fun things. Depends on llvm#81557
There was a problem hiding this comment.
I'm unconvinced by the runtime layer argument. Specifically, I'm interested in building libcxx for amdgpu without building libc for it, and it's plausible that libcxx on GPUs will not involve libunwind at all.
Likewise building compiler-rt for x64 and not nvptx, while building libc for nvptx and not x64 is probably a default configuration.
I would very much prefer cmake let us specify specific combinations instead of allowing a few blessed stacks.
GPU targets as cross compiling things, instead of as magic weird things with their own configuration, is the right direction.
|
@petrhosek please shout out if you want to block this in the current form - I have no doubt that the cmake could be better, but that's always true, and this would really help the gpu project. When someone sees a better way to express the same capability we'll be delighted to adopt it. |
llvm/runtimes/CMakeLists.txt
Outdated
| include(${LLVM_BINARY_DIR}/runtimes/${name}/Components.cmake OPTIONAL) | ||
| set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS ${LLVM_BINARY_DIR}/runtimes/${name}/Components.cmake) | ||
|
|
||
| set(runtime_names ${RUNTIME_NAMES}) | ||
| set(LLVM_ENABLE_RUNTIMES ${ARG_RUNTIMES}) |
There was a problem hiding this comment.
It's confusing to set this variable here since it may imply that it is somehow related to the loop below while it isn't, this should be moved to line 343.
jhuber6
force-pushed
the
RuntimesOverload
branch
2 times, most recently
from
a70563f to
c0495ee
Compare
llvm/runtimes/CMakeLists.txt
Outdated
| @@ -236,6 +236,7 @@ function(runtime_default_target) | |||
| endif() | |||
|
|
|||
| set_enable_per_target_runtime_dir() | |||
| set(LLVM_ENABLE_RUNTIMES ${ARG_RUNTIMES}) | |||
There was a problem hiding this comment.
Previously, we would passthrough LLVM_ENABLE_RUNTIMES as a global variable, but now we always pass in RUNTIMES as a function argument, and then set LLVM_ENABLE_RUNTIMES as a local variable shadowing the global one and rely on the passthrough mechanism.
That's quite obscure and potentially error prone, I think we should stop using the passthrough machinery and instead pass LLVM_ENABLE_RUNTIMES as an extra argument.
There was a problem hiding this comment.
I think I tired adding it to CMAKE_ARGS but it was being overridden by the passthrough version like you said. Changing PASSTHROUGH was a much bigger chance so I tried to keep it small. Maybe I could set LLVM_ENABLE_RUNTIMES to "" to make it more obvious.
|
@jhuber6 @JonChesterfield Can you give me a more concrete example of how you intend to build the full set of runtimes (including compiler-rt, libc and libcxx) for GPU using this mechanism? Maybe that would help me better understand the motivation. The reason I'm asking is because I'm still unconvinced by the simplicity argument. The reason for pushing this feature is to simplify the runtimes build compared to current implementation that requires multiple variables, but in my experience, building runtimes typically requires a number of variables regardless, so saving one variable for setting the list of runtimes makes it difficult to justify more complexity in the runtimes build for me and I'm worried we'll be adding a mechanism that in practice will only be useful in limited cases. For reference, here's an example from our runtimes build for Linux (which includes compiler-rt, libunwind, libcxxabi and libcxx): llvm-project/clang/cmake/caches/Fuchsia-stage2.cmake Lines 146 to 191 in c098f2d This inherent complexity is why we use cache files in practice, see for example https://github.com/llvm/llvm-project/tree/ea226d6693022b707f6acc6e399c12da8261de11/libcxx/cmake/caches. |
The issue with the current support is that it does not provide a way to disable a project for one of the runtimes targets. Right now I will say that a majority of users do not want the LLVM CPU Right now the suggested method would be. This would have the desired behavior of making the If there were some alternate way to specify "I want this project to only build with X runtimes" then I would also take that. I should also add that in my expected use-case if the user wanted CPU Or something. |
If you don't want |
jhuber6
force-pushed
the
RuntimesOverload
branch
from
c0495ee to
9ff130a
Compare
|
Today I have learned about the joys of @petrhosek I somewhat understand the difficulties here. It seems that the existing support tries to do |
Summary: This is a massive patch because it reworks the entire build and everything that depends on it. This is not split up because various bots would fail otherwise. I will attempt to describe the necessary changes here. This patch completely reworks how the GPU build is built and targeted. Previously, we used a standard runtimes build and handled both NVPTX and AMDGPU in a single build via multi-targeting. This added a lot of divergence in the build system and prevented us from doing various things like building for the CPU / GPU at the same time, or exporting the startup libraries or running tests without a full rebuild. The new appraoch is to handle the GPU builds as strict cross-compiling runtimes. The first step required llvm#81557 to allow the `LIBC` target to build for the GPU without touching the other targets. This means that the GPU uses all the same handling as the other builds in `libc`. The new expected way to build the GPU libc is with `LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`. The second step was reworking how we generated the embedded GPU library by moving it into the library install step. Where we previously had one `libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This patch includes the necessary clang / OpenMP changes to make that not break the bots when this lands. We unfortunately still require that the NVPTX target has an `internal` target for tests. This is because the NVPTX target needs to do LTO for the provided version (The offloading toolchain can handle it) but cannot use it for the native toolchain which is used for making tests. This approach is vastly suprerior in every way, allowing us to treat the GPU as a standard cross-compiling target. We can now install the GPU utilities to do things like use the offload tests and other fun things. Depends on llvm#81557
jhuber6
force-pushed
the
RuntimesOverload
branch
from
c360738 to
0417aec
Compare
Summary: This is a massive patch because it reworks the entire build and everything that depends on it. This is not split up because various bots would fail otherwise. I will attempt to describe the necessary changes here. This patch completely reworks how the GPU build is built and targeted. Previously, we used a standard runtimes build and handled both NVPTX and AMDGPU in a single build via multi-targeting. This added a lot of divergence in the build system and prevented us from doing various things like building for the CPU / GPU at the same time, or exporting the startup libraries or running tests without a full rebuild. The new appraoch is to handle the GPU builds as strict cross-compiling runtimes. The first step required llvm#81557 to allow the `LIBC` target to build for the GPU without touching the other targets. This means that the GPU uses all the same handling as the other builds in `libc`. The new expected way to build the GPU libc is with `LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`. The second step was reworking how we generated the embedded GPU library by moving it into the library install step. Where we previously had one `libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This patch includes the necessary clang / OpenMP changes to make that not break the bots when this lands. We unfortunately still require that the NVPTX target has an `internal` target for tests. This is because the NVPTX target needs to do LTO for the provided version (The offloading toolchain can handle it) but cannot use it for the native toolchain which is used for making tests. This approach is vastly suprerior in every way, allowing us to treat the GPU as a standard cross-compiling target. We can now install the GPU utilities to do things like use the offload tests and other fun things. Depends on llvm#81557
Summary: This is a massive patch because it reworks the entire build and everything that depends on it. This is not split up because various bots would fail otherwise. I will attempt to describe the necessary changes here. This patch completely reworks how the GPU build is built and targeted. Previously, we used a standard runtimes build and handled both NVPTX and AMDGPU in a single build via multi-targeting. This added a lot of divergence in the build system and prevented us from doing various things like building for the CPU / GPU at the same time, or exporting the startup libraries or running tests without a full rebuild. The new appraoch is to handle the GPU builds as strict cross-compiling runtimes. The first step required llvm#81557 to allow the `LIBC` target to build for the GPU without touching the other targets. This means that the GPU uses all the same handling as the other builds in `libc`. The new expected way to build the GPU libc is with `LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`. The second step was reworking how we generated the embedded GPU library by moving it into the library install step. Where we previously had one `libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This patch includes the necessary clang / OpenMP changes to make that not break the bots when this lands. We unfortunately still require that the NVPTX target has an `internal` target for tests. This is because the NVPTX target needs to do LTO for the provided version (The offloading toolchain can handle it) but cannot use it for the native toolchain which is used for making tests. This approach is vastly suprerior in every way, allowing us to treat the GPU as a standard cross-compiling target. We can now install the GPU utilities to do things like use the offload tests and other fun things. Depends on llvm#81557
Summary: This is a massive patch because it reworks the entire build and everything that depends on it. This is not split up because various bots would fail otherwise. I will attempt to describe the necessary changes here. This patch completely reworks how the GPU build is built and targeted. Previously, we used a standard runtimes build and handled both NVPTX and AMDGPU in a single build via multi-targeting. This added a lot of divergence in the build system and prevented us from doing various things like building for the CPU / GPU at the same time, or exporting the startup libraries or running tests without a full rebuild. The new appraoch is to handle the GPU builds as strict cross-compiling runtimes. The first step required llvm#81557 to allow the `LIBC` target to build for the GPU without touching the other targets. This means that the GPU uses all the same handling as the other builds in `libc`. The new expected way to build the GPU libc is with `LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`. The second step was reworking how we generated the embedded GPU library by moving it into the library install step. Where we previously had one `libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This patch includes the necessary clang / OpenMP changes to make that not break the bots when this lands. We unfortunately still require that the NVPTX target has an `internal` target for tests. This is because the NVPTX target needs to do LTO for the provided version (The offloading toolchain can handle it) but cannot use it for the native toolchain which is used for making tests. This approach is vastly suprerior in every way, allowing us to treat the GPU as a standard cross-compiling target. We can now install the GPU utilities to do things like use the offload tests and other fun things. Depends on llvm#81557
jhuber6
force-pushed
the
RuntimesOverload
branch
from
0417aec to
ab08233
Compare
|
Any remaining concerns @petrhosek? I'd like to land this but would like to wait for your blessing. |
Summary: Currently, the runtimes build allow users to optionally build for multiple target architectures via the `LLVM_RUNTIME_TARGETS` option. Once problem is that this applies to every single runtime the user has enabled, when it's possible that we may wish to enable a different set for just one target. The motivating example here is for handling GPU targets as cross-compiling. We want to be able to perform something like `LLVM_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda` to build runtimes targeting the GPU. However, the current support would force the other runtimes to be built for the GPU, when this definitely will not work. This patch attempts to work around this in a generic way by letting individual targets overload the set of enabled runtimes triples. The expected use would be to enable something like the following for targeting the GPU `libc` and in the future the GPU `libcxx`. ``` -DLLVM_ENABLE_PROJECTS='openmp;libcxx;libcxx-abi;libc' -DLLVM_LIBC_RUNTIME_TARGETS='nvptx64-nvidia-cuda;amdgcn-amd-amdhsa' ```
jhuber6
force-pushed
the
RuntimesOverload
branch
from
ab08233 to
a30ab48
Compare
Summary: This is a massive patch because it reworks the entire build and everything that depends on it. This is not split up because various bots would fail otherwise. I will attempt to describe the necessary changes here. This patch completely reworks how the GPU build is built and targeted. Previously, we used a standard runtimes build and handled both NVPTX and AMDGPU in a single build via multi-targeting. This added a lot of divergence in the build system and prevented us from doing various things like building for the CPU / GPU at the same time, or exporting the startup libraries or running tests without a full rebuild. The new appraoch is to handle the GPU builds as strict cross-compiling runtimes. The first step required llvm#81557 to allow the `LIBC` target to build for the GPU without touching the other targets. This means that the GPU uses all the same handling as the other builds in `libc`. The new expected way to build the GPU libc is with `LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`. The second step was reworking how we generated the embedded GPU library by moving it into the library install step. Where we previously had one `libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This patch includes the necessary clang / OpenMP changes to make that not break the bots when this lands. We unfortunately still require that the NVPTX target has an `internal` target for tests. This is because the NVPTX target needs to do LTO for the provided version (The offloading toolchain can handle it) but cannot use it for the native toolchain which is used for making tests. This approach is vastly suprerior in every way, allowing us to treat the GPU as a standard cross-compiling target. We can now install the GPU utilities to do things like use the offload tests and other fun things. Depends on llvm#81557
Summary: This is a massive patch because it reworks the entire build and everything that depends on it. This is not split up because various bots would fail otherwise. I will attempt to describe the necessary changes here. This patch completely reworks how the GPU build is built and targeted. Previously, we used a standard runtimes build and handled both NVPTX and AMDGPU in a single build via multi-targeting. This added a lot of divergence in the build system and prevented us from doing various things like building for the CPU / GPU at the same time, or exporting the startup libraries or running tests without a full rebuild. The new appraoch is to handle the GPU builds as strict cross-compiling runtimes. The first step required llvm#81557 to allow the `LIBC` target to build for the GPU without touching the other targets. This means that the GPU uses all the same handling as the other builds in `libc`. The new expected way to build the GPU libc is with `LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`. The second step was reworking how we generated the embedded GPU library by moving it into the library install step. Where we previously had one `libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This patch includes the necessary clang / OpenMP changes to make that not break the bots when this lands. We unfortunately still require that the NVPTX target has an `internal` target for tests. This is because the NVPTX target needs to do LTO for the provided version (The offloading toolchain can handle it) but cannot use it for the native toolchain which is used for making tests. This approach is vastly suprerior in every way, allowing us to treat the GPU as a standard cross-compiling target. We can now install the GPU utilities to do things like use the offload tests and other fun things. Depends on llvm#81557
|
This is a prereq for pull/81921 which is a huge decrease in overall complexity of our build scripts. Hopefully @petrhosek has some more ideas for cleaning up this area that we can apply post-commit. |
|
I looked at all I'm still not especially enthused about this feature, it adds additional complexity to the runtimes build and from what I can tell so far, you can achieve the same result with the existing implementation, and although that might require setting more options, I'm not sure it warrants the additional complexity. If there some specific things you believe aren't possible, it'd be great to provide an example so I can see if we could support those with the existing features. If we decide to go forward with change regardless, I'd like you to setup a builder that exercises it, ideally both presubmit and postsubmit. The problem we already have is that runtimes build has too many ways to spell the same thing which is making it frustratingly difficult to make changes. For example, in case of libc I have to verify that I'd also be curious to hear from @smeenai and @llvm-beanz as other reviewers of the runtimes build changes if they have other thoughts. |
|
Have you looked at pull/81921? That is a huge decrease in spurious complexity that we can't have without something functionally equivalent to this PR. I don't mind what horrendous cmake invocation is required to build things but I do want 81921, it lets me get rid of some really fragile infra for working with libc. |
|
AFAICT pull/81921 is not dependent on this change, this change just adds syntax sugar on top of the existing functionality provided by the runtimes build and so shouldn't be considered a blocker. |
Personally, I don't like splitting up the logic required to check if a runtime is enabled.
Fundamentally, this comes down to the question of whether or not
We will have an AMDGPU and NVPTX builder that will use it at a minimum. I think there was some talk with @jplehr to have some AMD presubmit support, but I don't think that's set up yet. This patch also somewhat simplifies the complexity here by explicitly setting up a list of runtimes per target I believe.
|
|
Both Keeping the current syntax and shipping the better behaviour today is much better than spending another week trying to make the syntax look different while the behavioural change bitrots. |
|
So, I think my main problem with the other support is that it forces explicitly adding Maybe |
I'm already working on a change for that since this is something I wanted to address for a while, I should have a PR ready later today. |
Okay, I will await that one eagerly. If we can get something that makes it just require something like the following, I could wrap this into the existing |
JonChesterfield
dismissed
their stale review
uninterested in contentious invocation syntax
Summary: This is a massive patch because it reworks the entire build and everything that depends on it. This is not split up because various bots would fail otherwise. I will attempt to describe the necessary changes here. This patch completely reworks how the GPU build is built and targeted. Previously, we used a standard runtimes build and handled both NVPTX and AMDGPU in a single build via multi-targeting. This added a lot of divergence in the build system and prevented us from doing various things like building for the CPU / GPU at the same time, or exporting the startup libraries or running tests without a full rebuild. The new appraoch is to handle the GPU builds as strict cross-compiling runtimes. The first step required llvm#81557 to allow the `LIBC` target to build for the GPU without touching the other targets. This means that the GPU uses all the same handling as the other builds in `libc`. The new expected way to build the GPU libc is with `LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`. The second step was reworking how we generated the embedded GPU library by moving it into the library install step. Where we previously had one `libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This patch includes the necessary clang / OpenMP changes to make that not break the bots when this lands. We unfortunately still require that the NVPTX target has an `internal` target for tests. This is because the NVPTX target needs to do LTO for the provided version (The offloading toolchain can handle it) but cannot use it for the native toolchain which is used for making tests. This approach is vastly suprerior in every way, allowing us to treat the GPU as a standard cross-compiling target. We can now install the GPU utilities to do things like use the offload tests and other fun things. Depends on llvm#81557
Summary: This is a massive patch because it reworks the entire build and everything that depends on it. This is not split up because various bots would fail otherwise. I will attempt to describe the necessary changes here. This patch completely reworks how the GPU build is built and targeted. Previously, we used a standard runtimes build and handled both NVPTX and AMDGPU in a single build via multi-targeting. This added a lot of divergence in the build system and prevented us from doing various things like building for the CPU / GPU at the same time, or exporting the startup libraries or running tests without a full rebuild. The new appraoch is to handle the GPU builds as strict cross-compiling runtimes. The first step required llvm#81557 to allow the `LIBC` target to build for the GPU without touching the other targets. This means that the GPU uses all the same handling as the other builds in `libc`. The new expected way to build the GPU libc is with `LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`. The second step was reworking how we generated the embedded GPU library by moving it into the library install step. Where we previously had one `libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This patch includes the necessary clang / OpenMP changes to make that not break the bots when this lands. We unfortunately still require that the NVPTX target has an `internal` target for tests. This is because the NVPTX target needs to do LTO for the provided version (The offloading toolchain can handle it) but cannot use it for the native toolchain which is used for making tests. This approach is vastly suprerior in every way, allowing us to treat the GPU as a standard cross-compiling target. We can now install the GPU utilities to do things like use the offload tests and other fun things. Depends on llvm#81557
Summary: This is a massive patch because it reworks the entire build and everything that depends on it. This is not split up because various bots would fail otherwise. I will attempt to describe the necessary changes here. This patch completely reworks how the GPU build is built and targeted. Previously, we used a standard runtimes build and handled both NVPTX and AMDGPU in a single build via multi-targeting. This added a lot of divergence in the build system and prevented us from doing various things like building for the CPU / GPU at the same time, or exporting the startup libraries or running tests without a full rebuild. The new appraoch is to handle the GPU builds as strict cross-compiling runtimes. The first step required #81557 to allow the `LIBC` target to build for the GPU without touching the other targets. This means that the GPU uses all the same handling as the other builds in `libc`. The new expected way to build the GPU libc is with `LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`. The second step was reworking how we generated the embedded GPU library by moving it into the library install step. Where we previously had one `libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This patch includes the necessary clang / OpenMP changes to make that not break the bots when this lands. We unfortunately still require that the NVPTX target has an `internal` target for tests. This is because the NVPTX target needs to do LTO for the provided version (The offloading toolchain can handle it) but cannot use it for the native toolchain which is used for making tests. This approach is vastly superior in every way, allowing us to treat the GPU as a standard cross-compiling target. We can now install the GPU utilities to do things like use the offload tests and other fun things. Some certain utilities need to be built with `--target=${LLVM_HOST_TRIPLE}` as well. I think this is a fine workaround as we will always assume that the GPU `libc` is a cross-build with a functioning host. Depends on #81557
|
Apologies for the radio silence here, I'm about to go on an extended leave soon and have had lots to wrap up before then. I generally agree with Petr that adding another configuration option (and in particular one that goes from project -> target, rather than target -> project) is adding extra testing burden that we'd ideally find a way to avoid. I haven't been able to look at the other diffs to weigh that against the simplifications permitted by this though. |
Summary:
Currently, the runtimes build allow users to optionally build for
multiple target architectures via the
LLVM_RUNTIME_TARGETSoption.Once problem is that this applies to every single runtime the user has
enabled, when it's possible that we may wish to enable a different set
for just one target.
The motivating example here is for handling GPU targets as
cross-compiling. We want to be able to perform something like
LLVM_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cudato buildruntimes targeting the GPU. However, the current support would force the
other runtimes to be built for the GPU, when this definitely will not
work.
This patch attempts to work around this in a generic way by letting
individual targets overload the set of enabled runtimes triples. The
expected use would be to enable something like the following for
targeting the GPU
libcand in the future the GPUlibcxx.