[PATCH] D147581: [libc] Ensure that the required clang tools are up-to-date for libc GPU

Tue Apr 4 17:11:08 PDT 2023

jhuber6 added inline comments.

================
Comment at: llvm/runtimes/CMakeLists.txt:403
+    if(LIBC_GPU_BUILD OR LIBC_GPU_ARCHITECTURES)
+      list(APPEND extra_deps clang-offload-packager nvptx-arch amdgpu-arch)
+    endif()
----------------
tra wrote:
> jhuber6 wrote:
> > tra wrote:
> > > Do these tools depend on something that may not be present on a build machine w/o GPU?  
> > > 
> > > I think `nvptx-arch` currently links with libcuda.so, which means that it will not build on machine w/o a NVIDIA GPU.  Ideally the app needs to dlopen(libcuda.so.1) and gracefully fail if it's not found.
> > > 
> > > 
> > > I think the dependency on nvptx-arch tools may need to be conditional on whether its build prerequisites are found.
> > Yes, `nvptx-arch` will attempt to dynamically open CUDA if it wasn't found beforehand. Otherwise they just depend on `ClangBasic` and other LLVM libraries that should be supported.
> If we already can dlopen it, then we should always do it. Linking with it explicitly just makes the binary unusable on machines w/o GPUs. E.g. you can just pack and ship it with the release build of clang. That a matter for a separate patch though.
So right now it just `dlopens` if it's not found on the machine. Honestly it probably would be best if we just always `dlopen`ed it since it would guarantee any build configuration would work somewhat. Honestly the only reason I haven't done that is because linking it directly makes it easier to use within an IDE since it has access to the header files.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147581