[libc-commits] [libc] [libc] Export the RPC interface from `libc` (PR #71432)

Joseph Huber via libc-commits libc-commits at lists.llvm.org
Tue Mar 19 06:46:33 PDT 2024


jhuber6 wrote:

> Left various comments inline.
> 
> I think exporting RPC from libc by wrapping the C++ in a layer of C is fundamentally the wrong thing to be doing and the signal to noise ratio of this patch somewhat supports that.
> 
> The RPC layer benefits from being in C++. We'd like it to be easily usable outside of libc, e.g. from the openmp runtime. The llvm libc is implemented in C++.
> 
> Instead of doing this force-through-C dance with the associated unsafety and complexity, and given that the libc project doesn't want to export C++ interfaces, we should move RPC to some other subproject. The new offload one seems an obvious fit. Then libc uses the C++ version directly from that subproject.
> 
> The analogy of libc depending on syscall, and rpc being an implementation of syscall, seems self evident. It's a historical quirk that we didn't have anywhere better to put the text files in the repo.

I more or less agree with the fact that this should eventually be moved somewhere else. What I'm imagining is that all the GPU specific utils, like wrappers around builtins and stuff, and this should all be in a header, likely in the `offload` project. The problem is that we don't have that project yet. But I've asked around and including from other projects is fine generally. The real difficulty is how to handle the RPC server portion. For example, with `printf` we like being able to use the LLVM libc printf interface as it lets us do custom parsing and handling of the string. Throwing libraries around a bunch of different CMake invocations is a huge pain in general so I'd need to think about it.

https://github.com/llvm/llvm-project/pull/71432


More information about the libc-commits mailing list