[LLVM] Replace use of `LLVM_RUNTIMES_TARGET` with `LLVM_DEFAULT_TARGET_TRIPLE` #136208

jhuber6 · 2025-04-17T21:40:56Z

Summary:
For purposes of determining the triple, it's more correct to use LLVM_DEFAULT_TARGET_TRIPLE.

llvmbot · 2025-04-17T21:41:36Z

@llvm/pr-subscribers-libc

Author: Joseph Huber (jhuber6)

Changes

Summary:
The multilib builds pass +name to the runtime target. We were using
this as a strict triple and passing it to the compiler. Parse out the
triple portion in this case.

Full diff: https://github.com/llvm/llvm-project/pull/136208.diff

1 Files Affected:

(modified) libc/cmake/modules/LLVMLibCArchitectures.cmake (+6)

diff --git a/libc/cmake/modules/LLVMLibCArchitectures.cmake b/libc/cmake/modules/LLVMLibCArchitectures.cmake
index 62f3a2e3bdb59..d2046d9270063 100644
--- a/libc/cmake/modules/LLVMLibCArchitectures.cmake
+++ b/libc/cmake/modules/LLVMLibCArchitectures.cmake
@@ -211,6 +211,12 @@ if(explicit_target_triple AND
             "GCC target triple (${libc_compiler_triple}) and the explicity "
             "specified target triple (${explicit_target_triple}) do not match.")
   else()
+    # Make sure we don't include any multilib specifiers.
+    string(FIND "${explicit_target_triple}" "+" plus_pos)
+    if(NOT plus_pos EQUAL -1)
+      string(SUBSTRING "${explicit_target_triple}" 0 ${plus_pos} explicit_target_triple)
+    endif()
+
     list(APPEND
          LIBC_COMPILE_OPTIONS_DEFAULT "--target=${explicit_target_triple}")
   endif()

petrhosek · 2025-04-18T08:51:56Z

Summary: The multilib builds pass +name to the runtime target.

This shouldn't happen, what's your build configuration?

jhuber6 · 2025-04-18T12:41:53Z

Summary: The multilib builds pass +name to the runtime target.

This shouldn't happen, what's your build configuration?

    -DRUNTIMES_x86_64-unknown-linux-gnu_LLVM_ENABLE_RUNTIMES=${RUNTIMES}                           \
    -DRUNTIMES_x86_64-unknown-linux-gnu+debug_LLVM_ENABLE_RUNTIMES=${RUNTIMES}                           \
    -DLLVM_RUNTIME_MULTILIBS=debug                                                                 \
    -DLLVM_RUNTIME_MULTILIB_debug_TARGETS=x86_64-unknown-linux-gnu                                 \

Something like this, I couldn't figure out how it expected it to work. If I just tried doing it any other way it would complain that the target didn't exist.

petrhosek · 2025-04-18T22:09:17Z

Summary: The multilib builds pass +name to the runtime target.

This shouldn't happen, what's your build configuration?
    -DRUNTIMES_x86_64-unknown-linux-gnu_LLVM_ENABLE_RUNTIMES=${RUNTIMES}                           \
    -DRUNTIMES_x86_64-unknown-linux-gnu+debug_LLVM_ENABLE_RUNTIMES=${RUNTIMES}                           \
    -DLLVM_RUNTIME_MULTILIBS=debug                                                                 \
    -DLLVM_RUNTIME_MULTILIB_debug_TARGETS=x86_64-unknown-linux-gnu                                 \
Something like this, I couldn't figure out how it expected it to work. If I just tried doing it any other way it would complain that the target didn't exist.

This looks correct but I suspect there might be a bug somewhere in the runtimes implementation since we shouldn't be passing the +${multilib} to the subbuild. I'd prefer addressing the issue rather than working around it inside the libc build. Let me reproduce this locally to figure out what's the problem.

jhuber6 · 2025-04-18T22:10:54Z

This looks correct but I suspect there might be a bug somewhere in the runtimes implementation since we shouldn't be passing the +${multilib} to the subbuild. I'd prefer addressing the issue rather than working around it inside the libc build. Let me reproduce this locally to figure out what's the problem.

Here's the full script I was using if it helps https://gist.github.com/jhuber6/91177b9ee4c11ae570f5bcc490271db7. I'm interested in making AMD's ROCm build move towards this instead of separate standalone builds for debugging and other support.

jhuber6 · 2025-04-21T14:09:18Z

@petrhosek Is there also an expected way to access the multilib dir? Like, if I have lib/x86_64-unknown-linux-gnu/debug do I need to pass that directory manually? Maybe we could accept --target=<triple>+debug to point there?

petrhosek · 2025-04-21T18:47:22Z

The issue is that we started using LLVM_RUNTIMES_TARGET in a way that wasn't intended for. When I introduced that variable, the "target" was meant as build target (i.e. Ninja or Make target) and used for purposes such as deriving the subdirectory name for build artifacts. It wasn't supposed to be used as the target triple, we should be still using LLVM_DEFAULT_TARGET_TRIPLE for that purpose as is already the case in other runtimes like compiler-rt, libunwind, libc++abi and libc++. Unfortunately, it looks like we already started using LLVM_RUNTIMES_TARGET as target triple in flang-rt and libc leading to the issue you've seen. Instead of trying to copt LLVM_RUNTIMES_TARGET, my preference would be to replace LLVM_RUNTIMES_TARGET in flang-rt and libc with LLVM_DEFAULT_TARGET_TRIPLE and then rename LLVM_RUNTIMES_TARGET to something like LLVM_RUNTIMES_SUBDIR to clarify its intended purpose.

jhuber6 · 2025-04-21T18:49:26Z

The issue is that we started using LLVM_RUNTIMES_TARGET in a way that wasn't intended for. When I introduced that variable, the "target" was meant as build target (i.e. Ninja or Make target) and used for purposes such as deriving the subdirectory name for build artifacts. It wasn't supposed to be used as the target triple, we should be still using LLVM_DEFAULT_TARGET_TRIPLE for that purpose as is already the case in other runtimes like compiler-rt, libunwind, libc++abi and libc++. Unfortunately, it looks like we already started using LLVM_RUNTIMES_TARGET as target triple in flang-rt and libc leading to the issue you've seen. Instead of trying to copt LLVM_RUNTIMES_TARGET, my preference would be to replace LLVM_RUNTIMES_TARGET in flang-rt and libc with LLVM_DEFAULT_TARGET_TRIPLE and then rename LLVM_RUNTIMES_TARGET to something like LLVM_RUNTIMES_SUBDIR to clarify its intended purpose.

That was my first question on the other PR, but you said to fix it in runtimes. I can do that.

jhuber6 · 2025-04-21T19:05:05Z

I get this error from the bot. Any clue what the intent of this check is...?

CMake Error at /home/runner/work/llvm-project/llvm-project/libc/cmake/modules/LLVMLibCArchitectures.cmake:210 (message):
  GCC target triple (x86_64-linux-gnu) and the explicity specified target
  triple (x86_64-unknown-linux-gnu) do not match.

Summary: The multilib builds pass `+name` to the runtime target. We were using this as a strict triple and passing it to the compiler. Parse out the triple portion in this case.

jhuber6 · 2025-04-22T03:51:00Z

I just turned that error into a warning, the problem is that GCC and LLVM set the triple slightly different and we can't pass --target= to GCC like with clang.

petrhosek · 2025-04-22T05:05:00Z

The issue is that we started using LLVM_RUNTIMES_TARGET in a way that wasn't intended for. When I introduced that variable, the "target" was meant as build target (i.e. Ninja or Make target) and used for purposes such as deriving the subdirectory name for build artifacts. It wasn't supposed to be used as the target triple, we should be still using LLVM_DEFAULT_TARGET_TRIPLE for that purpose as is already the case in other runtimes like compiler-rt, libunwind, libc++abi and libc++. Unfortunately, it looks like we already started using LLVM_RUNTIMES_TARGET as target triple in flang-rt and libc leading to the issue you've seen. Instead of trying to copt LLVM_RUNTIMES_TARGET, my preference would be to replace LLVM_RUNTIMES_TARGET in flang-rt and libc with LLVM_DEFAULT_TARGET_TRIPLE and then rename LLVM_RUNTIMES_TARGET to something like LLVM_RUNTIMES_SUBDIR to clarify its intended purpose.

That was my first question on the other PR, but you said to fix it in runtimes. I can do that.

Thanks for doing this cleanup!

llvm-ci · 2025-04-22T13:05:30Z

LLVM Buildbot has detected a new failure on builder libc-x86_64-debian-gcc-fullbuild-dbg running on libc-x86_64-debian-fullbuild while building flang-rt,libc at step 4 "annotate".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/131/builds/20393