[libc-commits] [PATCH] D149527: [libc] Support global constructors and destructors on NVPTX

Mon May 1 12:59:52 PDT 2023

tra added inline comments.

================
Comment at: libc/utils/gpu/loader/nvptx/CMakeLists.txt:12-13
   CUDA::cuda_driver
+  LLVMObject
+  LLVMSupport
 )
----------------
jhuber6 wrote:
> tra wrote:
> > jhuber6 wrote:
> > > tra wrote:
> > > > Can you check how long the clean build of the tool with `-j 6` would take now? If it's in the ballpark of a minute or so, we can probably live with that. Otherwise we should build the tool along with clang/LLVM, similar to how we deal with `libc-hdrgen`.
> > > Is this assume we need to rebuild the libraries? I figured these would be copied somewhere in the build environment. On my machine rebuilding the loader takes about five seconds.
> > We only copy the clang installation directory to the GPU machines, so when you build the tests, the build directory itself will be empty and the libraries would have to be rebuilt.
> > 
> > > On my machine rebuilding the loader takes about five seconds.
> > 
> > Is that a clean build? Can you check what `ninja clean; ninja -nv nvptx_loader | wc -l` shows?
> When done in the `runtimes/runtimes-bins` directory.
> ```
> [1/1] Cleaning all built files...
> Cleaning... 509 files.
> 3
> ```
Rebuilding it on a cloud machine with 6 cores may take too much. 
Un-ccached clean rebuild of LLVMSupport and LLVMObject on 6 real cores took ~2.5 minutes. On the build bots it will probably take ~2x that much (cloud counts hyperthereads as cores, IIUIC, and GPU bots have 6 of them, so only 3 physical cores) which would almost double the wall time of each test run which currently is between 5-8 minutes.

We could live with it short-term, but I think we do need to move nvptx_loader into the main clang build and allow libc tests to be configured to use it as an externally provided tool.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D149527