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

Joseph Huber via Phabricator via libc-commits libc-commits at lists.llvm.org
Tue Jun 27 11:22:17 PDT 2023


jhuber6 added a comment.

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

> Including system headers which know nothing about GPU architectures on the GPU causes a lot of grief in the offloading languages.

Yes, but not including system headers causes an equivalent amount of grief. The main problem is that we don't have nice system headers to use, but that's a far bigger ask than making a shim into what already exists.

> How necessary is it to put both our headers and the system one in the same translation unit, given that libc is meant to abstract over architectures? If a fundamental goal is bugward compat with glibc, we're probably better off including the glibc headers in whatever hacky way seems fit and providing an implementation shim that makes this work. E.g. for the div_t example, we swap the fields on the way into and out of the libc implementation.
>
> This setup would be
> Glibc headers
> Header hacks
> Llvm libc translation shim
> Llvm libc
>
> 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.


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