[libc-commits] [PATCH] D139839: [libc] Add a loader utility for AMDHSA architectures for testing

[Jon Chesterfield via Phabricator via libc-commits]

JonChesterfield added a comment.

In D139839#3993320 <https://reviews.llvm.org/D139839#3993320>, @jdoerfert wrote:

> The problem is that now we duplicate (and in the future extend) the "gpu launch" logic for each target.
> We are effectively creating yet another offloading runtime. We will invent new abstraction layers, new features will be added, etc.

There are two separate pieces to libc. One is all the library - stuff you get from including headers. Type definitions, strlen, printf, malloc, fopen,
The other is the C runtime. This is so tiny it tends to get forgotten about. For static executables it's walking ctor/dtor pointer arrays and a jump to main.

A GPU libc library has (relatively) wide applicability. There might be some uncertainty over what thread creation means in this context but libm and malloc are pretty clear.

The runtime part is a different game and worth considering separate to the above. An in tree use case is testing - libc, compiler backends, parts of other language runtimes.

A different use case is compiling code directly to the GPU and executing it without the offloading language models. A persistent kernel that watches the network card using DMA doesn't need to talk to the host.

My professional interest is in having openmp work more efficiently and robustly, and driving more code through that framework will help with that. However my interest in libc is not commercially driven - I want persistent kernels running lua on the GPU because that sounds awesome, and I'd rather not have debugging openmp on the critical path to making things like that work.

> This patch has 400 lines of HSA magic copied probably from OpenMP. We will need the same for CUDA, OneAPI, maybe OpenCL, ...
> Then we need extra logic in all of them to support allocators (via pre-allocation), in all their shapes (bump, free-lists, ...).
> Then we need to put RPC logic in them, again per target, and all of it is then not yet tested with OpenMP offload

The signal to noise ratio induced by the HSA interface might be the worst case. A bunch of this is wrapping the C API in C++ to make the callbacks easier to use, which really should be a hsa.hpp somewhere. Fundamentally though yes - there is plumbing needed behind the syscall part of a C runtime. To host on x64 you need some approximation to the linux kernel providing syscall, on top of which you get a libc loader to handle dlopen et al. To host on nvptx you need all that linux layer plus all of cuda plus some translation shim to put at least one kernel on the GPU. It's not as easy as one might like, but that's the abstraction we've been dealt.

I don't see why you're talking about scope creep though. The C runtime doesn't do very much. I can see it picking up global constructors / destructors when bringing up libc++ on top of it, and it needs 'syscall', but that's about it. If people want to use stuff beyond libc, well that's fine, they get to use non-libc libraries to do so.

RPC shouldn't care about the architecture. Doesn't need to anyway, if the API you use is syscall. Each side of the call sees some opaque target that it sends byes to.

> A loader using the existing offloading runtime:
>
> 1. does not require clang changes
> 2. requires 2 minimal files (shown below)
> 3. will work on all supported GPU targets, the MPI target, virtual GPU target, ...

What clang changes?

We can build a loader out of any GPU language we see fit, clang isn't involved. All it has to do is launch a kernel with one thread and tie up one end of syscall. If the in tree one is openmp, I'll just put a hsa one on my github so I've got a means of distinguishing bugs in openmp from bugs in libc. If other people want to walk through libomptarget while debugging libc tests, more power to them.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139839