[compiler-rt][builtins] Fix CMake builtin target flag

[thieta]

Summary

clang-cl doesn't support -target <target>, instead it only supports
--target=<target> so building a RUNTIME configuration for clang-cl
ended up in never building builtins. Which in turn lead to clang-cl
not being able to find the runtime libraries because we depend
on the compiler_rt.builtins.lib being in the runtime dir for the
Driver to add it as a candidate.

I don't think this should have any downsides since most the code
these days are using --target=<target> instead of the old syntax.

[mstorsjo]

LGTM, I think --target= is the generally preferred/recommended form these days anyway.

Other than that, I'm not entirely sure I understand exactly how you configure your build, but this change should be fine regardless.

[thieta]

In D120308#3337068, @mstorsjo wrote:

Other than that, I'm not entirely sure I understand exactly how you configure your build, but this change should be fine regardless.

cmake -GNinja -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_ENABLE_RUNTIMES="compiler-rt" ..\llvm

and then

ninja builtins

before this change it didn't build the runtime library - after this change it does.

[mstorsjo]

In D120308#3337077, @thieta wrote:

In D120308#3337068, @mstorsjo wrote:

Other than that, I'm not entirely sure I understand exactly how you configure your build, but this change should be fine regardless.

cmake -GNinja -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_ENABLE_RUNTIMES="compiler-rt" ..\llvm

and then

ninja builtins

before this change it didn't build the runtime library - after this change it does.

Hmm, ok. This is in an environment that defaults to a LLVM_DEFAULT_TRIPLE of *-windows-msvc I presume, but at what point within the runtimes setup does it switch to calling with the clang-cl frontend instead of the regular clang?

[thieta]

In D120308#3337090, @mstorsjo wrote:

Hmm, ok. This is in an environment that defaults to a LLVM_DEFAULT_TRIPLE of *-windows-msvc I presume, but at what point within the runtimes setup does it switch to calling with the clang-cl frontend instead of the regular clang?

Oh sorry - I guess it's a bit more complicated - it's a BOOTSTRAP build where the first stage is MSVC, then bootstrap defaults to pass clang-cl to the second stage, which I think is the recommended way to build LLVM on Windows (use clang-cl instead of clang).

But the same effect can be found by doing -DCMAKE_CXX_COMPILER=clang-cl to my example above.

[mstorsjo]

In D120308#3337100, @thieta wrote:

Oh sorry - I guess it's a bit more complicated - it's a BOOTSTRAP build where the first stage is MSVC, then bootstrap defaults to pass clang-cl to the second stage, which I think is the recommended way to build LLVM on Windows (use clang-cl instead of clang).

But the same effect can be found by doing -DCMAKE_CXX_COMPILER=clang-cl to my example above.

Ok, that explains it a little. But with LLVM_ENABLE_RUNTIMES, it shouldn't (AFAIK) use CMAKE_CXX_COMPILER to build the runtimes (which indeed could be anything, MSVC or GCC), but instead should use the newly built clang - and that's where I'm surprised to see that it prefers the clang-cl frontend there too, instead of the clang one. Or does it set up compiler-rt via LLVM_ENABLE_PROJECTS in the second stage? That would explain it.

[thieta]

In D120308#3337114, @mstorsjo wrote:

Ok, that explains it a little. But with LLVM_ENABLE_RUNTIMES, it shouldn't (AFAIK) use CMAKE_CXX_COMPILER to build the runtimes (which indeed could be anything, MSVC or GCC), but instead should use the newly built clang - and that's where I'm surprised to see that it prefers the clang-cl frontend there too, instead of the clang one. Or does it set up compiler-rt via LLVM_ENABLE_PROJECTS in the second stage? That would explain it.

I was curious and it took me a while to find - but it's selected here: https://github.com/llvm/llvm-project/blob/main/llvm/cmake/modules/LLVMExternalProjectUtils.cmake#L168

[mstorsjo]

In D120308#3337145, @thieta wrote:

In D120308#3337114, @mstorsjo wrote:

Ok, that explains it a little. But with LLVM_ENABLE_RUNTIMES, it shouldn't (AFAIK) use CMAKE_CXX_COMPILER to build the runtimes (which indeed could be anything, MSVC or GCC), but instead should use the newly built clang - and that's where I'm surprised to see that it prefers the clang-cl frontend there too, instead of the clang one. Or does it set up compiler-rt via LLVM_ENABLE_PROJECTS in the second stage? That would explain it.

I was curious and it took me a while to find - but it's selected here: https://github.com/llvm/llvm-project/blob/main/llvm/cmake/modules/LLVMExternalProjectUtils.cmake#L168

Thanks for the effort to dig that up! The patch is even more good to go then!

compiler-rt/cmake/Modules/BuiltinTests.cmake

function(try_compile_only output)
   endif()
   set(SIMPLE_C ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/src.c)
   file(WRITE ${SIMPLE_C} "${ARG_SOURCE}\n")
   string(REGEX MATCHALL "<[A-Za-z0-9_]*>" substitutions
          ${CMAKE_C_COMPILE_OBJECT})
 
   set(TRY_COMPILE_FLAGS "${ARG_FLAGS}")
   if(CMAKE_C_COMPILER_ID MATCHES Clang AND CMAKE_C_COMPILER_TARGET)
-    list(APPEND TRY_COMPILE_FLAGS "-target ${CMAKE_C_COMPILER_TARGET}")
+    list(APPEND TRY_COMPILE_FLAGS "--target=${CMAKE_C_COMPILER_TARGET}")
   endif()
 
   string(REPLACE ";" " " extra_flags "${TRY_COMPILE_FLAGS}")
 
   set(test_compile_command "${CMAKE_C_COMPILE_OBJECT}")
   foreach(substitution ${substitutions})
     if(substitution STREQUAL "<CMAKE_C_COMPILER>")
       string(REPLACE "<CMAKE_C_COMPILER>"