[PATCH] D146973: [Clang] Implicitly include LLVM libc headers for the GPU

Tue Mar 28 05:22:10 PDT 2023

aaron.ballman added a comment.

In D146973#4225645 <https://reviews.llvm.org/D146973#4225645>, @jhuber6 wrote:

> In D146973#4225641 <https://reviews.llvm.org/D146973#4225641>, @aaron.ballman wrote:
>
>>> This lets offloading languages such as OpenMP use the system string.h when compiling for the host and then the LLVM libc string.h when targeting the GPU.
>>
>> How do we avoid ABI issues when the two headers get sufficiently out of sync? (In general, I'm pretty surprised to hear we would want different headers for the GPU and the system -- does this affect conformance requirements from the C standard?)
>
> I'm not entirely sure if there's a good method. I think no matter what we do we'll need to implement some kind of 'glue'. I think most should be fine if we go by the C-standard. We expect pointer sizes and everything to be compatible at least.

Hmmm, I've had experience with SYCL as to how it goes when you have difference between host and device; those kinds of bugs are incredibly hard to track down. Pointer sizes being compatible is a good start, but you need integer widths, floating point formats, structure layout decisions, macro definitions, etc to all be the same as well. Having only one set of headers that can be used helps users avoid these sort of problems.

>> Excuse my ignorance on this point, but is llvm-libc intended to work with any compiler other than Clang? (e.g., will other compilers need to do this dance as well?)
>
> Right now the GPU target I'm working on can only be built with `clang` and it will be that way for the foreseeable future.

So we're comfortable painting ourselves into a corner where llvm-libc is only usable with Clang, depending on the target?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146973