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

Johannes Doerfert via Phabricator via libc-commits libc-commits at lists.llvm.org
Wed Jun 28 07:32:23 PDT 2023


jdoerfert added a comment.

In D153897#4456096 <https://reviews.llvm.org/D153897#4456096>, @JonChesterfield wrote:

> Nevertheless, openmp/cuda/hip presently include glibc headers directly on the gpu and patch around it. The dev teams involved seem committed to this strategy so I suggest we leave it in place.

The history of this is long. If we want to avoid system headers we run into various problems, including but not limited:
Missing extensions, missing/different macros, different function pointer value, missing includes (as a header on the path provides a function or an include that it doesn't have to according to the standard).
During the time we provided math functions w/o system headers we had a lot of complaints, lots of people found it pretty unusable. 
We might be able to work around those issue with our libc headers, but it is uncharted territory and I foresee problems. I'd be happy to try, but rather have a working fallback fist.

> I'd therefore like us to localise whatever header related hacks the offloading languages currently use where they are at present, i.e. in the overlay stuff in clang/lib/headers, and have absolutely none of it anywhere in libc. That allows the offloading languages to add or remove complexity, diverge from one another or converge as they see fit. This totally isolates libc from any adverse behaviour that results from those changes.

Localizing the hacks seems reasonable. Putting it in clang/lib/headers might not be the best idea though but I won't fight it. I was hoping to have it self contained in libc, but again, that is debatable.

In D153897#4453451 <https://reviews.llvm.org/D153897#4453451>, @jhuber6 wrote:

> In D153897#4453408 <https://reviews.llvm.org/D153897#4453408>, @JonChesterfield wrote:
>
>> While the pure, non-glibc-hybrid thing would just use the libc headers directly on the host and the GPU.
>
> I don't think we could have any other ordering. If we include the `libc` headers unmodified they will always result in a conflict with the system types, yet we still need them to tell the host / device which values are on the GPU. The approach taken here is to let the system headers define the types and then post-facto declare things on the GPU.

I agree, just libc headers will clash. That is why our current headers are annotated properly to make sure they will work well with host headers.
It is the curse of offloading that you need to keep the user program running the way it was, and make it work in the same build configuration, or people will take away it does not work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153897



More information about the libc-commits mailing list