[PATCH] D138862: [Clang] Do not set offload kind in a freestanding build
Artem Belevich via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Nov 28 16:02:01 PST 2022
tra added a comment.
In D138862#3955364 <https://reviews.llvm.org/D138862#3955364>, @jhuber6 wrote:
> So this patch was made because I'm trying to create a generic `libc` runtime for the GPU.
OK. That simplifies things. GPU-side non-kernel functions do not need anything from CUDA host runtime.
> The easiest way to build this was to use OpenMP. However, this creates a fatbinary with the kind set to `OpenMP` this means if someone linked with the built `libcgpu.a` for a CUDA application it would lead to the linker wrapper thinking it had to create registration code for both CUDA and OpenMP. So my goal was to allow a way for us to add "Nothing" as the offloading kind. This will result in only registering with the CUDA runtime in the previous example. I figured `-ffreestanding` was the best option to overload for this behaviour because it more or less implies that there is no standard runtime, in this case OpenMP.
OK. This makes sense in general.
However, we probably need some sort of safeguards warning users if they compile CUDA *kernels* or code w/ global variable in freestanding mode.
Also considering that `-freestanding` mode will not be very useful if the user does compile something that does need runtime, perhaps we can turn things around and always mark the GPU object as generic unless we do know that it requires runtime support?
This way you don't need `-freestanding` at all. Whether the resulting GPU object is generic would be determined by what we're compiling.
Later, if/when we actually want users to provide their own runtime (as opposed to not tying the generated code to specific runtime if we don't need to), we can implement a fully functional freestanding mode. I suspect we may need it for a while yet.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D138862/new/
https://reviews.llvm.org/D138862
More information about the cfe-commits
mailing list