This is an archive of the discontinued LLVM Phabricator instance.

[libc] Add initial support for a libc implementation for the GPU
ClosedPublic

Authored by jhuber6 on Nov 23 2022, 1:48 PM.

Details

Summary

This patch contains the initial support for building LLVM's libc as a
target for the GPU. Currently this only supports a handful of very basic
functions that can be implemented without an operating system. The GPU
code is build using the existing OpenMP toolchain. This allows us to
minimally change the existing codebase and get a functioning static
library. This patch allows users to create a static library called
libcgpu.a that contains fat binaries containing device IR.

Current limitations are the lack of test support and the fact that only
one target OS can be built at a time. That is, the user cannot get a
libc for Linux and one for the GPU simultaneously.

This introduces two new CMake variables to control the behavior
LLVM_LIBC_TARET_OS is exported so the user can now specify it to equal
"gpu". LLVM_LIBC_GPU_ARCHITECTURES is also used to configure how
many targets to build for at once.

Depends on D138607

Diff Detail

Event Timeline

jhuber6 created this revision.Nov 23 2022, 1:48 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptNov 23 2022, 1:48 PM
jhuber6 requested review of this revision.Nov 23 2022, 1:48 PM

This patch allows users to create a static library called libcpu.a that contains fat binaries containing device IR.

libcgpu.a, right?

jhuber6 edited the summary of this revision. (Show Details)Nov 25 2022, 2:33 PM

Thanks for the patch. The mechanical aspects of it LGTM but I have a few administrative questions and points to make:

  1. You should add a doc in the docs directory describing what exactly is a GPU build, its status, how to build and and how to test. You don't have to cram all of this in this patch, but I would like to hear that you do intend to follow up with appropriate documentation.
  2. What is the CI story for the GPU build? Everything, from who will own and maintain the CI builders, to the action that is to be taken if a patch breaks the GPU CI builders. Again, you don't have to stand up a GPU builders right away. You can choose to include the plan in the above documentation and work separately in setting up the buidlers.

Thanks for the patch. The mechanical aspects of it LGTM but I have a few administrative questions and points to make:

  1. You should add a doc in the docs directory describing what exactly is a GPU build, its status, how to build and and how to test. You don't have to cram all of this in this patch, but I would like to hear that you do intend to follow up with appropriate documentation.

Yes, I can add some documentation for how to run this build and how to use it.

  1. What is the CI story for the GPU build? Everything, from who will own and maintain the CI builders, to the action that is to be taken if a patch breaks the GPU CI builders. Again, you don't have to stand up a GPU builders right away. You can choose to include the plan in the above documentation and work separately in setting up the buidlers.

AMD has an active buildbot for testing the OpenMP runtime we could use for this. I haven't yet decided the best way to stand up tests for the GPU however. We can either use OpenMP offloading and modify the source code to run the region under test on the device or simply write GPU exclusive tests, maybe in another project. The problem with the former is it's not guaranteed to work as many existing test codes most likely contain code that can't be run on the GPU so we may still need some separation.

For the short term we should make the AMD GPU bot compile the GPU libc, then include it and run some tests on the functions we support. Long term we need a dedicated GPU buildbot for this (and other generic parts).

sivachandra accepted this revision.Nov 28 2022, 10:30 AM
  1. What is the CI story for the GPU build? Everything, from who will own and maintain the CI builders, to the action that is to be taken if a patch breaks the GPU CI builders. Again, you don't have to stand up a GPU builders right away. You can choose to include the plan in the above documentation and work separately in setting up the buidlers.

AMD has an active buildbot for testing the OpenMP runtime we could use for this. I haven't yet decided the best way to stand up tests for the GPU however. We can either use OpenMP offloading and modify the source code to run the region under test on the device or simply write GPU exclusive tests, maybe in another project. The problem with the former is it's not guaranteed to work as many existing test codes most likely contain code that can't be run on the GPU so we may still need some separation.

I am accepting this patch. We should follow up with the following actions:

  1. Add clear documentation about what and how of GPU build. Like, how to build, test etc.
  2. Get a CI builder building and testing the GPU build. If this is being done on a non-libc builder, we should call it out somewhere in the libc documentation so that libc developers can find all the relevant information.
  3. About tests, we should really be putting effort to use the same test code on all platforms. Different tests/systems for different platforms is added developer burden wrt writing them multiple times and then maintaining those multiple flavors.

There should be some sort of urgency in addressing the above items. Need not happen now/today/tomorrow, but I think a reasonable time frame is that all of the above should be addressed within a month of landing this patch.

This revision is now accepted and ready to land.Nov 28 2022, 10:30 AM

I am accepting this patch. We should follow up with the following actions:

Thanks for being open to these additions to LLVM's libc.

  1. Add clear documentation about what and how of GPU build. Like, how to build, test etc.

I'll try to add some basic documentation and include a list of supported functions soon.

  1. Get a CI builder building and testing the GPU build. If this is being done on a non-libc builder, we should call it out somewhere in the libc documentation so that libc developers can find all the relevant information.
  2. About tests, we should really be putting effort to use the same test code on all platforms. Different tests/systems for different platforms is added developer burden wrt writing them multiple times and then maintaining those multiple flavors.

Keeping the code common would be ideal. One problem is that the GPU currently doesn't support aliases, but there's less ambiguity on the GPU side when it comes to the libc functions so we may not need them to test. We may also want to avoid relying on other runtimes like OpenMP which may introduce their own bugs so it may be worthwhile to include our own launcher inside the test infrastructure. I'll look into it further as we definitely need tests.

There should be some sort of urgency in addressing the above items. Need not happen now/today/tomorrow, but I think a reasonable time frame is that all of the above should be addressed within a month of landing this patch.

That should be doable.