jhuber6 added a comment.

In D138862#3955339 <https://reviews.llvm.org/D138862#3955339>, @tra wrote:

>> we should expect it to be handled externally.
>
> Can you give more details on how it will work? Something/somewhere would need 
> to generate the glue code to register kernels w/ CUDA runtime.
> Are you saying that we'll have some way to tell the final linking stage that 
> all offloaded functions with unspecified offload kind must be treated as if 
> they need runtime X, and the appropriate glue will be generated for them?
>
> If you mean that it would need to be handled by the end user, it may be 
> problematic as they would need to have access to the GPU binaries, the kernel 
> names they contain and would need to further generate host-side kernel launch 
> stubs matching the kernel names.

So this patch was made because I'm trying to create a generic `libc` runtime 
for the GPU. 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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138862/new/

https://reviews.llvm.org/D138862

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to