[libc-commits] [PATCH] D153897: [libc][hdr-gen] Add special offloading handling for the GPU target

[Joseph Huber via Phabricator via libc-commits]

jhuber6 added a comment.

In D153897#4454762 <https://reviews.llvm.org/D153897#4454762>, @sivachandra wrote:

> I am still not convinced about the "soundness" of the solution. I am on vacation but will try to spend more time on this tomorrow (late evening/night US west coast time) so that we can move forward on this in whatever way. I think the RFC is missing a comparison of alternatives. If you can describe the potential alternative approaches and their pros and cons, it will become easier for me (and others I am sure) to understand (and may be even concur). One of the alternatives that I had mentioned previously is separating out the offloading language use case and standalone GPU use case. IIRC, you wanted to combine them as a matter of convenience - I think you should describe that in the RFC for others benefit (and at the least for the sake of record).

Thanks a lot for looking into this admittedly weird and unfortunate quirk of offloading languages and sorry to disturb your vacation. Yes, this presents a lot of unique difficulties because we are trying to provide a library for something like a kind-of-hosted-but-not-really interface. I don't think separating the headers is a big distinction, it's the same approach in the end. Whether we have a single header that `ifdefs` it off, or two headers that we conditionally include, it'll be the same to the preprocessor at the end of the day. I went with a single header because it is easier to implement and use since the existing workflow only creates one header and I didn't see a compelling reason to separate them given the extra work.

For alternative approaches,  I've mentioned before that if we had a unified environment all of this can go away save for the device declarations. That's a solution but is a much, much bigger ask at this point in time. Another alternative would be to only export the functions via the LLVM-libc and include that in a separate wrapper header, maybe in `clang/lib/Headers/__`, e.g. like the following

  #include_next <stdlib.h>
  
  #define __DEVICE __attribute__((device))
  
  #pragma omp begin declare target
  #include <__llvm_libc_declarations/stdlib.h>
  #pragma omp end declare target

Where that file could look like

  #ifndef __DEVICE
  #define __DEVICE
  #endif
  
  int abs(int) __DEVICE;
  ...

This would have the benefit of keeping CUDA / OpenMP weirdness out of `libc` and we'd be more or less free to hack our way to victory without anyone in `libc` smelling it. The downside is that we would still need a few workarounds, e.g. for something like `errno` we'd need to copy the declaration from `libc`, or with `atexit` we would need to manually define the `__atexit_handler_t` somewhere. Doing this would basically need a special operation to `libc-hdrgen` that only emits the entrypoints and gets rid of the other stuff, so we might end up still needing the `%%begin` and `%%end` mess unless we want to parse it more completely.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153897