You had asked me a question about nvtpx on
https://reviews.llvm.org/D67867. I did some homework on that and below
is what I have learnt.
For CUDA/nvptx, a libc in general might be irrelevant. However, I
learned from Art (copied in this email) that there is a desire to have
a single library of math functions that clang can rely on for the GPU.
So, even if a libc in general could be irrelevant, a subset of the
libc might indeed become relevant for GPUs.
We want llvm-libc to expose a thin layer of C symbols over the
underlying C++ implementation library. My patch
(https://reviews.llvm.org/rL373764) showcased one way of doing this
for ELF using the section attribute followed by a post-processing
step. We might have to take a different approach for nvptx because ELF
like sections and tooling might not be feasible/available (as there is
no linking phase during GPU-side comiplation for NVIDIA GPUs). Art
explained to me that device code undergoes whole program analysis by
LLVM. Hence, we can provide an explicit C wrapper layer over the C++
implementation library. If source level wrappers are not desirable, we
can consider using IR level aliases (will we have to deal with mangled
names??). This gives the benefit that, while it looks like a normal C
function call from the user's point of view, the whole program
analysis performed by LLVM will eliminate the additional wrapper call
preventing any performance hits.