Files
llvm-project/compiler-rt/CMakeLists.txt
Yaxun (Sam) Liu e0b4a7063f [compiler-rt][profile] Use runtimes-libc-headers in the GPU runtimes build (#192814)
When compiler-rt is built for a GPU target in the same runtimes build
as LLVM-libc, the profile sources `#include <string.h>`, `<limits.h>`,
... Those headers are generated by LLVM-libc for the GPU triple.

A concrete example is the amdgcn runtimes build:

    -DLLVM_RUNTIME_TARGETS='default;amdgcn-amd-amdhsa'
    -DRUNTIMES_amdgcn-amd-amdhsa_LLVM_ENABLE_RUNTIMES='compiler-rt;libc'
    -DRUNTIMES_amdgcn-amd-amdhsa_RUNTIMES_USE_LIBC=llvm-libc

Even though `libc` is configured before `compiler-rt`, both sets of
targets live in the same ninja graph and race each other. Ninja can
start compiling `compiler-rt/lib/profile/InstrProfiling.c` before
LLVM-libc has finished generating its GPU `string.h`, and even when
hdrgen has finished, the profile compile needs `-isystem` pointing at
the generated header tree.

Use the runtimes-side libc-provider abstraction in
`runtimes/cmake/Modules/HandleLibC.cmake`:

  - at compiler-rt top level, `include(HandleLibC)` when
    `LLVM_RUNTIMES_BUILD` is set, so all compiler-rt subcomponents can
    reuse the `runtimes-libc-*` targets. `libcxx` / `libcxxabi` /
    `libunwind` include it the same way at their top-level CMakeLists.
  - in `compiler-rt/lib/profile/CMakeLists.txt`, when the GPU build
    sees the sibling `runtimes-libc-headers` target, pass it through
    `LINK_LIBS` of `add_compiler_rt_runtime(clang_rt.profile ...)`.

In the `llvm-libc` case this pulls in LLVM-libc's `libc-headers`
(`-isystem <build>/include/<triple>`), waits for
`generate-libc-headers`, and adds `-nostdlibinc` so the profile compile
does not consult host C library paths.

The dependency is added only when `COMPILER_RT_GPU_BUILD` is on and the
sibling `runtimes-libc-headers` target actually exists, so host
compiler-rt builds, standalone compiler-rt builds, and runtimes builds
without LLVM-libc selected are unchanged.

`add_compiler_rt_runtime` passes `LINK_LIBS` to
`target_link_libraries(<libname> PRIVATE ...)`, so the include path is
used when compiling the profile target itself but is not propagated to
downstream consumers of `libclang_rt.profile.a`.

Related: PR #177665.
2026-04-21 17:53:34 -04:00

40 KiB