We already use the amdgpu-arch and nvptx-arch tools to determine the
GPU architectures the user's system supports. We can provide
LIBC_GPU_ARCHITECTURES=native to allow users to easily build support
for only the one found on their system. This also cleans up the code
somewhat.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Add if incase the tools aren't found for some reason. (This should never reasonably happen).
libc/cmake/modules/prepare_libc_gpu_build.cmake | ||
---|---|---|
74 | Is that a singular architecture, or can we supply a list? We may want to be able to build for a set of user-specified GPUs and, if I can dream out loud, allow specifying which GPU to run them on, so I could just do niunja check-libc-sm_70 and it would run the tests with CUDA_VISIBLE_DEVICES=<ID of sm_70 GPU> |
libc/cmake/modules/prepare_libc_gpu_build.cmake | ||
---|---|---|
74 | Right now it's a singular architecture. The reason for this is because the internal objects used for testing and the ones that will be exported via the libcgpu.a library are separate compilations. Since the existing libc testing architecture only ever expected a single executable, it was easiest to implement it this way. Basically, the libcgpu.a library contains N architectures packed into a single file and the internal testing implementation just builds for one. I don't think it's impossible to support what you're asking, it would just require a lot more CMake. |
LGTM in general.
libc/cmake/modules/prepare_libc_gpu_build.cmake | ||
---|---|---|
74 | Can we build a set of per-GPU test executables and then just pick one of them to run libc tests? |
libc/cmake/modules/prepare_libc_gpu_build.cmake | ||
---|---|---|
74 | So, libc works by making a bunch of target according to the directories and filename. So we compile some file and create the CMake target libc.src.string.memcmp. We then attach the compiled files to this target via some CMake property. We could potentially just attach several files to different properties and use the list of architectures to pull them out while building the tests. I didn't spend much time on changing it because I figured it would be sufficient to just test a single one at a time. But it would be interesting to be able to test an AMD and NVIDIA GPU at the same time. |
libc/cmake/modules/prepare_libc_gpu_build.cmake | ||
---|---|---|
74 | My strawman idea was to, roughly, wrap the part of cmake which generates test targets into a loop iterating over GPUs, which would create the same targets, but with a GPU-specifc suffix, which should in theory make it a largely mechanical change. But I'm also not familiar with the details of libc cmake, so if it's more invasive than that, targeting single arch for tests is fine. |
libc/cmake/modules/prepare_libc_gpu_build.cmake | ||
---|---|---|
74 | Yeah, it's mostly just a convenience. The test files are built differently, they're intended to be compiled directly to a GPU image and then executed via the loader. The GPU library on the other hand is all LLVM-IR for LTO that's packaged into a fatbinary for the "new driver". It's certainly doable, but it's not very high on my priorities right now. |
Is that a singular architecture, or can we supply a list?
We may want to be able to build for a set of user-specified GPUs and, if I can dream out loud, allow specifying which GPU to run them on, so I could just do niunja check-libc-sm_70 and it would run the tests with CUDA_VISIBLE_DEVICES=<ID of sm_70 GPU>