mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-17 06:56:44 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/compiler-rt/cmake/Modules/CompilerRTUtils.cmake

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

647 lines
26 KiB
CMake
Raw Normal View History

[CMake] Adding some missing CMake includes. NFC. This happens to be working now because the includes exist in another CMake file that is included before this one. That will change with upcoming refactoring. llvm-svn: 267912
2016-04-28 18:22:01 +00:00
include(CMakePushCheckState)
include(CheckSymbolExists)
CMake: create AddCompilerRT module and implement convenience add_compiler_rt_object_library function llvm-svn: 172826
2013-01-18 16:05:21 +00:00
# Because compiler-rt spends a lot of time setting up custom compile flags,
# define a handy helper function for it. The compile flags setting in CMake
# has serious issues that make its syntax challenging at best.
function(set_target_compile_flags target)
[CMake][compiler-rt] Use COMPILE_OPTIONS and LINK_OPTIONS This avoids the need for string-ification and lets CMake deduplicate potentially duplicate flags. Differential Revision: https://reviews.llvm.org/D122750
2022-03-30 10:33:40 -07:00
set_property(TARGET ${target} PROPERTY COMPILE_OPTIONS ${ARGN})
CMake: create AddCompilerRT module and implement convenience add_compiler_rt_object_library function llvm-svn: 172826
2013-01-18 16:05:21 +00:00
endfunction()
function(set_target_link_flags target)
[CMake][compiler-rt] Use COMPILE_OPTIONS and LINK_OPTIONS This avoids the need for string-ification and lets CMake deduplicate potentially duplicate flags. Differential Revision: https://reviews.llvm.org/D122750
2022-03-30 10:33:40 -07:00
set_property(TARGET ${target} PROPERTY LINK_OPTIONS ${ARGN})
CMake: create AddCompilerRT module and implement convenience add_compiler_rt_object_library function llvm-svn: 172826
2013-01-18 16:05:21 +00:00
endfunction()
Add a CMake option COMPILER_RT_DEBUG for building runtimes with full debug info. Differential Revision: http://llvm-reviews.chandlerc.com/D1984 llvm-svn: 193449
2013-10-25 23:03:34 +00:00
# Set the variable var_PYBOOL to True if var holds a true-ish string,
# otherwise set it to False.
macro(pythonize_bool var)
if (${var})
set(${var}_PYBOOL True)
else()
set(${var}_PYBOOL False)
endif()
endmacro()
[CMake] Simplify setting compile flag disabling RTTI llvm-svn: 201547
2014-02-18 07:52:40 +00:00
[CMake] Make append_if semantics similar to those used in LLVM llvm-svn: 203773
2014-03-13 09:31:36 +00:00
# Appends value to all lists in ARGN, if the condition is true.
[compiler-rt] compiler-rt's CMake append_if function clashes with LLVM's, let's rename it to append_list_if Doing s/append_if/append_list_if/, no functional change. http://reviews.llvm.org/D5739 llvm-svn: 219860
2014-10-15 22:47:54 +00:00
macro(append_list_if condition value)
[CMake] Make append_if semantics similar to those used in LLVM llvm-svn: 203773
2014-03-13 09:31:36 +00:00
if(${condition})
foreach(list ${ARGN})
list(APPEND ${list} ${value})
endforeach()
[CMake] Simplify setting compile flag disabling RTTI llvm-svn: 201547
2014-02-18 07:52:40 +00:00
endif()
endmacro()
[CMake] Use /W3 instead of -Wall on Windows. Remove add_definitions abuse. llvm-svn: 203786
2014-03-13 11:31:10 +00:00
# Appends value to all strings in ARGN, if the condition is true.
macro(append_string_if condition value)
if(${condition})
foreach(str ${ARGN})
set(${str} "${${str}} ${value}")
endforeach()
endif()
endmacro()
[cmake] Address Samsonov's post-commit review of r262723 Reviewers: samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17896 llvm-svn: 262770
2016-03-05 10:01:04 +00:00
macro(append_rtti_flag polarity list)
[cmake] Fix append_rtti_flag macro and bad var name llvm-svn: 279450
2016-08-22 18:30:37 +00:00
if(${polarity})
[cmake] Address Samsonov's post-commit review of r262723 Reviewers: samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17896 llvm-svn: 262770
2016-03-05 10:01:04 +00:00
append_list_if(COMPILER_RT_HAS_FRTTI_FLAG -frtti ${list})
append_list_if(COMPILER_RT_HAS_GR_FLAG /GR ${list})
else()
append_list_if(COMPILER_RT_HAS_FNO_RTTI_FLAG -fno-rtti ${list})
append_list_if(COMPILER_RT_HAS_GR_FLAG /GR- ${list})
endif()
[CMake] Simplify setting compile flag disabling RTTI llvm-svn: 201547
2014-02-18 07:52:40 +00:00
endmacro()
[ASan] Only include rpc headers if they are available. Reviewed at http://reviews.llvm.org/D8698 llvm-svn: 234470
2015-04-09 08:06:49 +00:00
[compiler-rt] list_union() is actually an intersect operation. Rename it. Summary: Given: set(T1 a b c) set(T2 b c d) message("T1=${T1}") message("T2=${T2}") list_union(T3 T1 T2) message("T3=${T3}") cmake emitted: T1=a;b;c T2=b;c;d T3=b;c Reviewers: beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16580 llvm-svn: 258916
2016-01-27 09:28:01 +00:00
macro(list_intersect output input1 input2)
[CMake] Add experimental support for building compiler-rt for iOS Summary: This is a reunification of three separate reviews D11073, D11082, D11083. Having them separate was not constructive even though the patches were smaller because it led to fragmented conversations, and this is really all about one change. This patch incorporates feedback from samsonov, and refactors the hacky darwin code out of the root CMakeLists.txt and int config-ix.cmake. Reviewers: zaks.anna, bogner, kubabrecka, chandlerc, samsonov Subscribers: jevinskie, filcab, llvm-commits Differential Revision: http://reviews.llvm.org/D11820 llvm-svn: 244948
2015-08-13 20:38:16 +00:00
set(${output})
foreach(it ${${input1}})
list(FIND ${input2} ${it} index)
if( NOT (index EQUAL -1))
list(APPEND ${output} ${it})
endif()
endforeach()
endmacro()
[CMake] [NFC] Move macro definitions out of config-ix.cmake This change should have no functional impact, it just moves some macro definitions out of config-ix.cmake into CompilerRTUtils.cmake. This step will allow these macros to be re-used by the separated builtin build. llvm-svn: 261108
2016-02-17 16:57:38 +00:00
build: allow building a specific set of sanitizers Introduce a new CMake option `COMPILER_RT_SANITIZERS_TO_BUILD` which takes either a special token `all` (default) which will preserve the current behaviour or a CMake list of sanitizers to build. It will still perform the normal checks if the sanitizer is requested. It only permits a further means to exclude a particular sanitizer. This gives finer grained control than `COMPILER_RT_BUILD_SANITIZERS` which only gives an all or nothing control. llvm-svn: 279253
2016-08-19 15:13:21 +00:00
function(list_replace input_list old new)
set(replaced_list)
foreach(item ${${input_list}})
if(${item} STREQUAL ${old})
list(APPEND replaced_list ${new})
else()
list(APPEND replaced_list ${item})
endif()
endforeach()
set(${input_list} "${replaced_list}" PARENT_SCOPE)
endfunction()
[CMake] [NFC] Move macro definitions out of config-ix.cmake This change should have no functional impact, it just moves some macro definitions out of config-ix.cmake into CompilerRTUtils.cmake. This step will allow these macros to be re-used by the separated builtin build. llvm-svn: 261108
2016-02-17 16:57:38 +00:00
# Takes ${ARGN} and puts only supported architectures in @out_var list.
function(filter_available_targets out_var)
set(archs ${${out_var}})
foreach(arch ${ARGN})
list(FIND COMPILER_RT_SUPPORTED_ARCH ${arch} ARCH_INDEX)
if(NOT (ARCH_INDEX EQUAL -1) AND CAN_TARGET_${arch})
list(APPEND archs ${arch})
endif()
endforeach()
set(${out_var} ${archs} PARENT_SCOPE)
endfunction()
[compiler-rt] Support building builtins for a single target This is used when building builtins for multiple targets as part of LLVM runtimes. Differential Revision: https://reviews.llvm.org/D26653 llvm-svn: 289489
2016-12-12 23:14:02 +00:00
# Add $arch as supported with no additional flags.
macro(add_default_target_arch arch)
set(TARGET_${arch}_CFLAGS "")
set(CAN_TARGET_${arch} 1)
list(APPEND COMPILER_RT_SUPPORTED_ARCH ${arch})
endmacro()
[CMake] [NFC] Move macro definitions out of config-ix.cmake This change should have no functional impact, it just moves some macro definitions out of config-ix.cmake into CompilerRTUtils.cmake. This step will allow these macros to be re-used by the separated builtin build. llvm-svn: 261108
2016-02-17 16:57:38 +00:00
function(check_compile_definition def argstring out_var)
if("${def}" STREQUAL "")
set(${out_var} TRUE PARENT_SCOPE)
return()
endif()
cmake_push_check_state()
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} ${argstring}")
check_symbol_exists(${def} "" ${out_var})
cmake_pop_check_state()
endfunction()
# test_target_arch(<arch> <def> <target flags...>)
# Checks if architecture is supported: runs host compiler with provided
# flags to verify that:
# 1) <def> is defined (if non-empty)
# 2) simple file can be successfully built.
# If successful, saves target flags for this architecture.
macro(test_target_arch arch def)
set(TARGET_${arch}_CFLAGS ${ARGN})
Make cmake link flag naming consistent Summary: The build system was inconsistent in its naming conventions for link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS, for consistency with cmake's LINK_FLAGS property. This patch should make it easier to search the source code for uses of link flags, as well as providing the benefit of improved style and consistency. Reviewers: compnerd, beanz Subscribers: kubabrecka, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28506 llvm-svn: 291539
2017-01-10 04:33:04 +00:00
set(TARGET_${arch}_LINK_FLAGS ${ARGN})
[CMake] [NFC] Move macro definitions out of config-ix.cmake This change should have no functional impact, it just moves some macro definitions out of config-ix.cmake into CompilerRTUtils.cmake. This step will allow these macros to be re-used by the separated builtin build. llvm-svn: 261108
2016-02-17 16:57:38 +00:00
set(argstring "")
foreach(arg ${ARGN})
set(argstring "${argstring} ${arg}")
endforeach()
check_compile_definition("${def}" "${argstring}" HAS_${arch}_DEF)
[compiler-rt][cmake] Don't reset CAN_TARGET_${arch} on every cmake invocation. Allowing this variable to be cached makes it possible to repair the MIPS buildbots in lieu of either fixing the mips64 sanitizer issues or fixing the detection of mips64 support (which I think was changed by r268977 but didn't take effect on this buildbot until the last couple days) so that it returns to not being built on these buildbots. llvm-svn: 276402
2016-07-22 10:15:09 +00:00
if(NOT DEFINED CAN_TARGET_${arch})
if(NOT HAS_${arch}_DEF)
set(CAN_TARGET_${arch} FALSE)
elseif(TEST_COMPILE_ONLY)
[compiler-rt] Fix false positive detection of a target in compile-only mode When `compiler-rt` is configured as a runtime, the configure-time target detection for builtins is done in compile-only mode, which is basically a test of whether the newly-built `clang` can compile a simple program with an additional flag (`-m32` and `-m64` in my case). The problem is that on my Debian system `clang` can compile `int foo(int x, int y) { return x + y; }` with `-m32` but fails to include `limits.h` (or any other target-specific header) for the `i386` target: ``` $ /path/to/build/./bin/clang --target=x86_64-unknown-linux-gnu -DVISIBILITY_HIDDEN -O3 -DNDEBUG -m32 -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-i386.dir/absvdi2.c.o -MF CMakeFiles/clang_rt.builtins-i386.dir/absvdi2.c.o.d -o CMakeFiles/clang_rt.builtins-i386.dir/absvdi2.c.o -c /path/to/src/compiler-rt/lib/builtins/absvdi2.c In file included from /path/to/src/compiler-rt/lib/builtins/absvdi2.c:13: In file included from /path/to/src/compiler-rt/lib/builtins/int_lib.h:93: In file included from /path/to/build/lib/clang/15.0.0/include/limits.h:21: In file included from /usr/include/limits.h:25: /usr/include/features.h:364:12: fatal error: 'sys/cdefs.h' file not found ^~~~~~~~~~~~~ 1 error generated. ``` This is an attempt to make the target detection more robust: extend the test program with `#include <limits.h>`. Differential Revision: https://reviews.llvm.org/D127975
2022-06-22 16:10:33 +03:00
try_compile_only(CAN_TARGET_${arch}
SOURCE "#include <limits.h>\nint foo(int x, int y) { return x + y; }\n"
FLAGS ${TARGET_${arch}_CFLAGS})
[compiler-rt][cmake] Don't reset CAN_TARGET_${arch} on every cmake invocation. Allowing this variable to be cached makes it possible to repair the MIPS buildbots in lieu of either fixing the mips64 sanitizer issues or fixing the detection of mips64 support (which I think was changed by r268977 but didn't take effect on this buildbot until the last couple days) so that it returns to not being built on these buildbots. llvm-svn: 276402
2016-07-22 10:15:09 +00:00
else()
[CMake] Rename back SIMPLE_SOURCE to compile as C++ This was changed in rL276151 and causes problems if the C++ compiler does not support the same arches as the C compiler. For the builtins, only the C compiler is tested in try_compile_only. Additionally, -fno-exceptions is passed in (if available) to work around the case where no libunwind is available. Differential Revision: https://reviews.llvm.org/D23654 llvm-svn: 282054
2016-09-21 05:44:06 +00:00
set(FLAG_NO_EXCEPTIONS "")
if(COMPILER_RT_HAS_FNO_EXCEPTIONS_FLAG)
set(FLAG_NO_EXCEPTIONS " -fno-exceptions ")
endif()
[compiler-rt] respect CMAKE_EXE_LINKER_FLAGS in compiler and library tests Summary: check_cxx_compiler_flag and check_library_exists could fail because they ignored CMAKE_EXE_LINKER_FLAGS and therefore would always fail to produce executables. Cmake policy CMP0056 fixes this, but was explicitly set to OLD in our CMakeLists because it caused problems with test_target_arch. This change sets the policy to NEW to fix the problem with the compiler and library tests, and temporarily clears CMAKE_EXE_LINKER_FLAGS inside test_target_arch to emulate the old behavior there. This allows, for example, LTO builds that require lld to succeed. Reviewers: davidxl, beanz Reviewed By: beanz Subscribers: fjricci, dberris, mgorny, mehdi_amini, tejohnson, rnk, llvm-commits Differential Revision: https://reviews.llvm.org/D31098 llvm-svn: 298413
2017-03-21 18:25:35 +00:00
set(SAVED_CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS})
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${argstring}")
Revert "[CMake] Use a different source depending on C++ support" This reverts commit r332924 and followup r332936 silencing a warning. The change breaks the build on x86 if there is no 32-bit version of the C++ libraries, see discussion in https://reviews.llvm.org/D47169. llvm-svn: 334903
2018-06-17 09:51:33 +00:00
try_compile(CAN_TARGET_${arch} ${CMAKE_BINARY_DIR} ${SIMPLE_SOURCE}
[CMake] Rename back SIMPLE_SOURCE to compile as C++ This was changed in rL276151 and causes problems if the C++ compiler does not support the same arches as the C compiler. For the builtins, only the C compiler is tested in try_compile_only. Additionally, -fno-exceptions is passed in (if available) to work around the case where no libunwind is available. Differential Revision: https://reviews.llvm.org/D23654 llvm-svn: 282054
2016-09-21 05:44:06 +00:00
COMPILE_DEFINITIONS "${TARGET_${arch}_CFLAGS} ${FLAG_NO_EXCEPTIONS}"
[compiler-rt] respect CMAKE_EXE_LINKER_FLAGS in compiler and library tests Summary: check_cxx_compiler_flag and check_library_exists could fail because they ignored CMAKE_EXE_LINKER_FLAGS and therefore would always fail to produce executables. Cmake policy CMP0056 fixes this, but was explicitly set to OLD in our CMakeLists because it caused problems with test_target_arch. This change sets the policy to NEW to fix the problem with the compiler and library tests, and temporarily clears CMAKE_EXE_LINKER_FLAGS inside test_target_arch to emulate the old behavior there. This allows, for example, LTO builds that require lld to succeed. Reviewers: davidxl, beanz Reviewed By: beanz Subscribers: fjricci, dberris, mgorny, mehdi_amini, tejohnson, rnk, llvm-commits Differential Revision: https://reviews.llvm.org/D31098 llvm-svn: 298413
2017-03-21 18:25:35 +00:00
OUTPUT_VARIABLE TARGET_${arch}_OUTPUT)
set(CMAKE_EXE_LINKER_FLAGS ${SAVED_CMAKE_EXE_LINKER_FLAGS})
[compiler-rt][cmake] Don't reset CAN_TARGET_${arch} on every cmake invocation. Allowing this variable to be cached makes it possible to repair the MIPS buildbots in lieu of either fixing the mips64 sanitizer issues or fixing the detection of mips64 support (which I think was changed by r268977 but didn't take effect on this buildbot until the last couple days) so that it returns to not being built on these buildbots. llvm-svn: 276402
2016-07-22 10:15:09 +00:00
endif()
[CMake] [NFC] Move macro definitions out of config-ix.cmake This change should have no functional impact, it just moves some macro definitions out of config-ix.cmake into CompilerRTUtils.cmake. This step will allow these macros to be re-used by the separated builtin build. llvm-svn: 261108
2016-02-17 16:57:38 +00:00
endif()
if(${CAN_TARGET_${arch}})
list(APPEND COMPILER_RT_SUPPORTED_ARCH ${arch})
[compiler-rt] Fix target architecture matching Summary: Use stricter comparisons for architecture. This prevents cmake from failing for sysroots which can only compile armhf and not arm, since arm MATCHES armhf is true, while arm STREQUAL armhf is false. Reviewers: beanz, compnerd Subscribers: aemerson, llvm-commits Differential Revision: https://reviews.llvm.org/D22473 llvm-svn: 276148
2016-07-20 18:06:31 +00:00
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" STREQUAL "${arch}" AND
[CMake] [NFC] Move macro definitions out of config-ix.cmake This change should have no functional impact, it just moves some macro definitions out of config-ix.cmake into CompilerRTUtils.cmake. This step will allow these macros to be re-used by the separated builtin build. llvm-svn: 261108
2016-02-17 16:57:38 +00:00
COMPILER_RT_HAS_EXPLICIT_DEFAULT_TARGET_TRIPLE)
# Bail out if we cannot target the architecture we plan to test.
message(FATAL_ERROR "Cannot compile for ${arch}:\n${TARGET_${arch}_OUTPUT}")
endif()
endmacro()
[CMake] detect_target_arch needs to be moved to Utils This macro is called from the base config, so it can't live in config-ix, it needs to be in the utils. I suspect the only reason this hasn't caused problems is that nobody is building the Android builtins from the builtins subdirectory. llvm-svn: 271693
2016-06-03 17:34:02 +00:00
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-14 15:04:30 -07:00
macro(detect_target_arch)
[compiler-rt] Initial support for builtins on GPU targets (#95304) Summary: This patch adds initial support to build the `builtins` library for GPU targets. Primarily this requires adding a few new architectures for `amdgcn` and `nvptx64`. I built this using the following invocations. ```console $ cmake ../compiler-rt -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Release -GNinja -DCMAKE_C_COMPILER_TARGET=<nvptx64-nvidia-cuda|amdgcn-amd-amdhsa> -DCMAKE_CXX_COMPILER_TARGET=<nvptx64-nvidia-cuda|amdgcn-amd-amdhsa> -DCMAKE_C_COMPILER_WORKS=1 -DCMAKE_CXX_COMPILER_WORKS=1 -DLLVM_CMAKE_DIR=../cmake/Modules -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON -C ../compiler-rt/cmake/caches/GPU.cmake ``` Some pointers would be appreciated for how to test this using a standard (non-default target only) build. GPU builds are somewhat finnicky. We only expect this to be built with a sufficiently new clang, as it's the only compiler that supports the target and output we distribute. Distribution is done as LLVM-IR blobs for now. GPUs have little backward compatibility, so linking object files is left to a future patch. More work is necessary to build correctly for all targets and ship into the correct clang resource directory. Additionally we need to use the `libc` project's support for running unit tests.
2024-07-10 15:07:11 -05:00
check_symbol_exists(__AMDGPU__ "" __AMDGPU)
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-14 15:04:30 -07:00
check_symbol_exists(__arm__ "" __ARM)
[compiler-rt][builtins] Add several helper functions for AVR __mulqi3 : int8 multiplication __mulhi3 : int16 multiplication _exit : golobal terminator Reviewed By: MaskRay, aykevl Differential Revision: https://reviews.llvm.org/D123200
2022-04-06 10:45:50 +00:00
check_symbol_exists(__AVR__ "" __AVR)
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-14 15:04:30 -07:00
check_symbol_exists(__aarch64__ "" __AARCH64)
check_symbol_exists(__x86_64__ "" __X86_64)
check_symbol_exists(__i386__ "" __I386)
[compiler-rt] Add hexagon architecture to cmake (#98650) Add hexagon to detect_target_arch, test_target macros.
2024-07-12 20:10:03 -05:00
check_symbol_exists(__hexagon__ "" __HEXAGON)
[compiler-rt][builtins] Support builtins for LoongArch Initial builtins for LoongArch. Add loongarch64 to ALL_CRT_SUPPORTED_ARCH list. Support fe_getround and fe_raise_inexact in builtins. Differential Revision: https://reviews.llvm.org/D136338
2022-11-01 20:08:06 +08:00
check_symbol_exists(__loongarch__ "" __LOONGARCH)
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-14 15:04:30 -07:00
check_symbol_exists(__mips__ "" __MIPS)
check_symbol_exists(__mips64__ "" __MIPS64)
[compiler-rt] Initial support for builtins on GPU targets (#95304) Summary: This patch adds initial support to build the `builtins` library for GPU targets. Primarily this requires adding a few new architectures for `amdgcn` and `nvptx64`. I built this using the following invocations. ```console $ cmake ../compiler-rt -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Release -GNinja -DCMAKE_C_COMPILER_TARGET=<nvptx64-nvidia-cuda|amdgcn-amd-amdhsa> -DCMAKE_CXX_COMPILER_TARGET=<nvptx64-nvidia-cuda|amdgcn-amd-amdhsa> -DCMAKE_C_COMPILER_WORKS=1 -DCMAKE_CXX_COMPILER_WORKS=1 -DLLVM_CMAKE_DIR=../cmake/Modules -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON -C ../compiler-rt/cmake/caches/GPU.cmake ``` Some pointers would be appreciated for how to test this using a standard (non-default target only) build. GPU builds are somewhat finnicky. We only expect this to be built with a sufficiently new clang, as it's the only compiler that supports the target and output we distribute. Distribution is done as LLVM-IR blobs for now. GPUs have little backward compatibility, so linking object files is left to a future patch. More work is necessary to build correctly for all targets and ship into the correct clang resource directory. Additionally we need to use the `libc` project's support for running unit tests.
2024-07-10 15:07:11 -05:00
check_symbol_exists(__NVPTX__ "" __NVPTX)
[compiler-rt][AIX] Add CMake support for 32-bit Power builds This patch enables support for building compiler-rt builtins for 32-bit Power arch on AIX. For now, we leave out the specialized ppc builtin implementations for 128-bit long double and friends since those will need some special handling for AIX. Reviewed By: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D87383
2020-09-03 11:40:13 -04:00
check_symbol_exists(__powerpc__ "" __PPC)
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-14 15:04:30 -07:00
check_symbol_exists(__powerpc64__ "" __PPC64)
check_symbol_exists(__powerpc64le__ "" __PPC64LE)
check_symbol_exists(__riscv "" __RISCV)
check_symbol_exists(__s390x__ "" __S390X)
check_symbol_exists(__sparc "" __SPARC)
check_symbol_exists(__sparcv9 "" __SPARCV9)
check_symbol_exists(__wasm32__ "" __WEBASSEMBLY32)
check_symbol_exists(__wasm64__ "" __WEBASSEMBLY64)
check_symbol_exists(__ve__ "" __VE)
[compiler-rt] Initial support for builtins on GPU targets (#95304) Summary: This patch adds initial support to build the `builtins` library for GPU targets. Primarily this requires adding a few new architectures for `amdgcn` and `nvptx64`. I built this using the following invocations. ```console $ cmake ../compiler-rt -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Release -GNinja -DCMAKE_C_COMPILER_TARGET=<nvptx64-nvidia-cuda|amdgcn-amd-amdhsa> -DCMAKE_CXX_COMPILER_TARGET=<nvptx64-nvidia-cuda|amdgcn-amd-amdhsa> -DCMAKE_C_COMPILER_WORKS=1 -DCMAKE_CXX_COMPILER_WORKS=1 -DLLVM_CMAKE_DIR=../cmake/Modules -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON -C ../compiler-rt/cmake/caches/GPU.cmake ``` Some pointers would be appreciated for how to test this using a standard (non-default target only) build. GPU builds are somewhat finnicky. We only expect this to be built with a sufficiently new clang, as it's the only compiler that supports the target and output we distribute. Distribution is done as LLVM-IR blobs for now. GPUs have little backward compatibility, so linking object files is left to a future patch. More work is necessary to build correctly for all targets and ship into the correct clang resource directory. Additionally we need to use the `libc` project's support for running unit tests.
2024-07-10 15:07:11 -05:00
if(__AMDGPU)
add_default_target_arch(amdgcn)
elseif(__ARM)
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-14 15:04:30 -07:00
add_default_target_arch(arm)
[compiler-rt][builtins] Add several helper functions for AVR __mulqi3 : int8 multiplication __mulhi3 : int16 multiplication _exit : golobal terminator Reviewed By: MaskRay, aykevl Differential Revision: https://reviews.llvm.org/D123200
2022-04-06 10:45:50 +00:00
elseif(__AVR)
add_default_target_arch(avr)
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-14 15:04:30 -07:00
elseif(__AARCH64)
add_default_target_arch(aarch64)
elseif(__X86_64)
[compiler-rt] Add platform detection support for x32 Currently, the compiler-rt build system checks only whether __X86_64 is defined to determine whether the default compiler-rt target arch is x86_64. Since x32 defines __X86_64 as well, we must also check that the default pointer size is eight bytes and not four bytes to properly detect a 64-bit x86_64 compiler-rt default target arch. Reviewed By: hvdijk, vitalybuka Differential Revision: https://reviews.llvm.org/D99988
2021-06-11 19:44:04 +01:00
if(CMAKE_SIZEOF_VOID_P EQUAL "4")
add_default_target_arch(x32)
elseif(CMAKE_SIZEOF_VOID_P EQUAL "8")
add_default_target_arch(x86_64)
else()
message(FATAL_ERROR "Unsupported pointer size for X86_64")
endif()
[compiler-rt] Add hexagon architecture to cmake (#98650) Add hexagon to detect_target_arch, test_target macros.
2024-07-12 20:10:03 -05:00
elseif(__HEXAGON)
add_default_target_arch(hexagon)
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-14 15:04:30 -07:00
elseif(__I386)
add_default_target_arch(i386)
[compiler-rt][builtins] Support builtins for LoongArch Initial builtins for LoongArch. Add loongarch64 to ALL_CRT_SUPPORTED_ARCH list. Support fe_getround and fe_raise_inexact in builtins. Differential Revision: https://reviews.llvm.org/D136338
2022-11-01 20:08:06 +08:00
elseif(__LOONGARCH)
if(CMAKE_SIZEOF_VOID_P EQUAL "4")
add_default_target_arch(loongarch32)
elseif(CMAKE_SIZEOF_VOID_P EQUAL "8")
add_default_target_arch(loongarch64)
else()
message(FATAL_ERROR "Unsupported pointer size for LoongArch")
endif()
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-14 15:04:30 -07:00
elseif(__MIPS64) # must be checked before __MIPS
add_default_target_arch(mips64)
elseif(__MIPS)
add_default_target_arch(mips)
[compiler-rt] Initial support for builtins on GPU targets (#95304) Summary: This patch adds initial support to build the `builtins` library for GPU targets. Primarily this requires adding a few new architectures for `amdgcn` and `nvptx64`. I built this using the following invocations. ```console $ cmake ../compiler-rt -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Release -GNinja -DCMAKE_C_COMPILER_TARGET=<nvptx64-nvidia-cuda|amdgcn-amd-amdhsa> -DCMAKE_CXX_COMPILER_TARGET=<nvptx64-nvidia-cuda|amdgcn-amd-amdhsa> -DCMAKE_C_COMPILER_WORKS=1 -DCMAKE_CXX_COMPILER_WORKS=1 -DLLVM_CMAKE_DIR=../cmake/Modules -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON -C ../compiler-rt/cmake/caches/GPU.cmake ``` Some pointers would be appreciated for how to test this using a standard (non-default target only) build. GPU builds are somewhat finnicky. We only expect this to be built with a sufficiently new clang, as it's the only compiler that supports the target and output we distribute. Distribution is done as LLVM-IR blobs for now. GPUs have little backward compatibility, so linking object files is left to a future patch. More work is necessary to build correctly for all targets and ship into the correct clang resource directory. Additionally we need to use the `libc` project's support for running unit tests.
2024-07-10 15:07:11 -05:00
elseif(__NVPTX)
add_default_target_arch(nvptx64)
[compiler-rt][AIX] Add CMake support for 32-bit Power builds This patch enables support for building compiler-rt builtins for 32-bit Power arch on AIX. For now, we leave out the specialized ppc builtin implementations for 128-bit long double and friends since those will need some special handling for AIX. Reviewed By: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D87383
2020-09-03 11:40:13 -04:00
elseif(__PPC64) # must be checked before __PPC
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-14 15:04:30 -07:00
add_default_target_arch(powerpc64)
elseif(__PPC64LE)
add_default_target_arch(powerpc64le)
[compiler-rt][AIX] Add CMake support for 32-bit Power builds This patch enables support for building compiler-rt builtins for 32-bit Power arch on AIX. For now, we leave out the specialized ppc builtin implementations for 128-bit long double and friends since those will need some special handling for AIX. Reviewed By: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D87383
2020-09-03 11:40:13 -04:00
elseif(__PPC)
add_default_target_arch(powerpc)
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-14 15:04:30 -07:00
elseif(__RISCV)
if(CMAKE_SIZEOF_VOID_P EQUAL "4")
add_default_target_arch(riscv32)
elseif(CMAKE_SIZEOF_VOID_P EQUAL "8")
add_default_target_arch(riscv64)
else()
Fix some small typos in compiler-rt. NFC (#133388)
2025-03-28 12:51:13 -07:00
message(FATAL_ERROR "Unsupported XLEN for RISC-V")
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-14 15:04:30 -07:00
endif()
elseif(__S390X)
add_default_target_arch(s390x)
elseif(__SPARCV9)
add_default_target_arch(sparcv9)
elseif(__SPARC)
add_default_target_arch(sparc)
elseif(__WEBASSEMBLY32)
add_default_target_arch(wasm32)
elseif(__WEBASSEMBLY64)
add_default_target_arch(wasm64)
elseif(__VE)
add_default_target_arch(ve)
endif()
endmacro()
[CMake][Compiler-rt] Compute `LLVM_MAIN_SRC_DIR` assuming the monorepo layout. When doing a standalone compiler-rt build we currently rely on getting information from the `llvm-config` binary. Previously we would rely on calling `llvm-config --src-root` to find the LLVM sources. Unfortunately the returned path could easily be wrong if the sources were built on another machine. Now that compiler-rt is part of a monorepo we can easily fix this problem by finding the LLVM source tree next to `compiler-rt` in the monorepo. We do this regardless of whether or not the `llvm-config` binary is available which moves us one step closer to not requiring `llvm-config` to be available. To try avoid anyone breaking anyone who relies on the current behavior, if the path assuming the monorepo layout doesn't exist we invoke `llvm-config --src-root` to get the path. A deprecation warning is emitted if this path is taken because we should remove this path in the future given that other runtimes already assume the monorepo layout. We also now emit a warning if `LLVM_MAIN_SRC_DIR` does not exist. The intention is that this should be a hard error in future but to avoid breaking existing users we'll keep this as a warning for now. rdar://76016632 Differential Revision: https://reviews.llvm.org/D99620
2021-03-30 12:50:59 -07:00
function(get_compiler_rt_root_source_dir ROOT_DIR_VAR)
# Compute the path to the root of the Compiler-RT source tree
# regardless of how the project was configured.
#
# This function is useful because using `${CMAKE_SOURCE_DIR}`
# is error prone due to the numerous ways Compiler-RT can be
# configured.
#
# `ROOT_DIR_VAR` - the name of the variable to write the result to.
#
# TODO(dliew): When CMake min version is 3.17 or newer use
# `CMAKE_CURRENT_FUNCTION_LIST_DIR` instead.
if ("${ROOT_DIR_VAR}" STREQUAL "")
message(FATAL_ERROR "ROOT_DIR_VAR cannot be empty")
endif()
# Compiler-rt supports different source root paths.
# Handle each case here.
set(PATH_TO_COMPILER_RT_SOURCE_ROOT "")
if (DEFINED CompilerRTBuiltins_SOURCE_DIR)
# Compiler-RT Builtins standalone build.
# `llvm-project/compiler-rt/lib/builtins`
set(PATH_TO_COMPILER_RT_SOURCE_ROOT "${CompilerRTBuiltins_SOURCE_DIR}/../../")
[CMake][compiler-rt] Make CRT separately buildable This is useful when building a complete toolchain to ensure that CRT is built after builtins but before the rest of the compiler-rt. Differential Revision: https://reviews.llvm.org/D120682
2022-02-28 12:21:11 -08:00
elseif (DEFINED CompilerRTCRT_SOURCE_DIR)
# Compiler-RT CRT standalone build.
# `llvm-project/compiler-rt/lib/crt`
set(PATH_TO_COMPILER_RT_SOURCE_ROOT "${CompilerRTCRT_SOURCE_DIR}/../../")
[CMake][Compiler-rt] Compute `LLVM_MAIN_SRC_DIR` assuming the monorepo layout. When doing a standalone compiler-rt build we currently rely on getting information from the `llvm-config` binary. Previously we would rely on calling `llvm-config --src-root` to find the LLVM sources. Unfortunately the returned path could easily be wrong if the sources were built on another machine. Now that compiler-rt is part of a monorepo we can easily fix this problem by finding the LLVM source tree next to `compiler-rt` in the monorepo. We do this regardless of whether or not the `llvm-config` binary is available which moves us one step closer to not requiring `llvm-config` to be available. To try avoid anyone breaking anyone who relies on the current behavior, if the path assuming the monorepo layout doesn't exist we invoke `llvm-config --src-root` to get the path. A deprecation warning is emitted if this path is taken because we should remove this path in the future given that other runtimes already assume the monorepo layout. We also now emit a warning if `LLVM_MAIN_SRC_DIR` does not exist. The intention is that this should be a hard error in future but to avoid breaking existing users we'll keep this as a warning for now. rdar://76016632 Differential Revision: https://reviews.llvm.org/D99620
2021-03-30 12:50:59 -07:00
elseif(DEFINED CompilerRT_SOURCE_DIR)
# Compiler-RT standalone build.
# `llvm-project/compiler-rt`
set(PATH_TO_COMPILER_RT_SOURCE_ROOT "${CompilerRT_SOURCE_DIR}")
elseif (EXISTS "${CMAKE_SOURCE_DIR}/../compiler-rt")
# In tree build with LLVM as the root project.
# See `llvm-project/projects/`.
# Assumes monorepo layout.
set(PATH_TO_COMPILER_RT_SOURCE_ROOT "${CMAKE_SOURCE_DIR}/../compiler-rt")
else()
message(FATAL_ERROR "Unhandled Compiler-RT source root configuration.")
endif()
get_filename_component(ROOT_DIR "${PATH_TO_COMPILER_RT_SOURCE_ROOT}" ABSOLUTE)
if (NOT EXISTS "${ROOT_DIR}")
message(FATAL_ERROR "Path \"${ROOT_DIR}\" doesn't exist")
endif()
# Sanity check: Make sure we can locate the current source file via the
# computed path.
set(PATH_TO_CURRENT_FILE "${ROOT_DIR}/cmake/Modules/CompilerRTUtils.cmake")
if (NOT EXISTS "${PATH_TO_CURRENT_FILE}")
message(FATAL_ERROR "Could not find \"${PATH_TO_CURRENT_FILE}\"")
endif()
set("${ROOT_DIR_VAR}" "${ROOT_DIR}" PARENT_SCOPE)
endfunction()
[CMake] Load LLVMConfig for standalone build of builtins Therefore move some code into reusable macros. Differential Revision: https://reviews.llvm.org/D22866 llvm-svn: 277418
2016-08-02 05:51:05 +00:00
macro(load_llvm_config)
[compiler-rt] Switch from llvm-config to find_package(LLVM) Replace the use of the deprecated `llvm-config` tool with LLVM's CMake files for detecting LLVM in standalone builds. Differential Revision: https://reviews.llvm.org/D137024
2022-10-29 19:03:37 +02:00
if (LLVM_CONFIG_PATH AND NOT LLVM_CMAKE_DIR)
message(WARNING
"LLVM_CONFIG_PATH is deprecated, please use LLVM_CMAKE_DIR instead")
# Compute the path to the LLVM install prefix and pass it as LLVM_CMAKE_DIR,
# CMake will locate the appropriate lib*/cmake subdirectory from there.
# For example. for -DLLVM_CONFIG_PATH=/usr/lib/llvm/16/bin/llvm-config
# this will yield LLVM_CMAKE_DIR=/usr/lib/llvm/16.
get_filename_component(LLVM_CMAKE_DIR "${LLVM_CONFIG_PATH}" DIRECTORY)
get_filename_component(LLVM_CMAKE_DIR "${LLVM_CMAKE_DIR}" DIRECTORY)
Revert "[compiler-rt] Switch from llvm-config to find_package(LLVM)" This reverts commit 37acf9bdd4686397a6d37000e8d3fe35f456a860. It broke a buildbot.
2022-11-01 05:49:24 +01:00
endif()
[CMake][Compiler-rt] Compute `LLVM_MAIN_SRC_DIR` assuming the monorepo layout. When doing a standalone compiler-rt build we currently rely on getting information from the `llvm-config` binary. Previously we would rely on calling `llvm-config --src-root` to find the LLVM sources. Unfortunately the returned path could easily be wrong if the sources were built on another machine. Now that compiler-rt is part of a monorepo we can easily fix this problem by finding the LLVM source tree next to `compiler-rt` in the monorepo. We do this regardless of whether or not the `llvm-config` binary is available which moves us one step closer to not requiring `llvm-config` to be available. To try avoid anyone breaking anyone who relies on the current behavior, if the path assuming the monorepo layout doesn't exist we invoke `llvm-config --src-root` to get the path. A deprecation warning is emitted if this path is taken because we should remove this path in the future given that other runtimes already assume the monorepo layout. We also now emit a warning if `LLVM_MAIN_SRC_DIR` does not exist. The intention is that this should be a hard error in future but to avoid breaking existing users we'll keep this as a warning for now. rdar://76016632 Differential Revision: https://reviews.llvm.org/D99620
2021-03-30 12:50:59 -07:00
# Compute path to LLVM sources assuming the monorepo layout.
# We don't set `LLVM_MAIN_SRC_DIR` directly to avoid overriding a user provided
# CMake cache value.
get_compiler_rt_root_source_dir(COMPILER_RT_ROOT_SRC_PATH)
get_filename_component(LLVM_MAIN_SRC_DIR_DEFAULT "${COMPILER_RT_ROOT_SRC_PATH}/../llvm" ABSOLUTE)
if (NOT EXISTS "${LLVM_MAIN_SRC_DIR_DEFAULT}")
# TODO(dliew): Remove this legacy fallback path.
message(WARNING
"LLVM source tree not found at \"${LLVM_MAIN_SRC_DIR_DEFAULT}\". "
"You are not using the monorepo layout. This configuration is DEPRECATED.")
endif()
[compiler-rt] Switch from llvm-config to find_package(LLVM) Replace the use of the deprecated `llvm-config` tool with LLVM's CMake files for detecting LLVM in standalone builds. Differential Revision: https://reviews.llvm.org/D137024
2022-10-29 19:03:37 +02:00
find_package(LLVM HINTS "${LLVM_CMAKE_DIR}")
if (NOT LLVM_FOUND)
message(WARNING "UNSUPPORTED COMPILER-RT CONFIGURATION DETECTED: "
"LLVM cmake package not found.\n"
"Reconfigure with -DLLVM_CMAKE_DIR=/path/to/llvm.")
else()
list(APPEND CMAKE_MODULE_PATH "${LLVM_DIR}")
# Turn into CACHE PATHs for overwritting
set(LLVM_BINARY_DIR "${LLVM_BINARY_DIR}" CACHE PATH "Path to LLVM build tree")
set(LLVM_LIBRARY_DIR "${LLVM_LIBRARY_DIR}" CACHE PATH "Path to llvm/lib")
set(LLVM_TOOLS_BINARY_DIR "${LLVM_TOOLS_BINARY_DIR}" CACHE PATH "Path to llvm/bin")
set(LLVM_INCLUDE_DIR ${LLVM_INCLUDE_DIRS} CACHE PATH "Path to llvm/include and any other header dirs needed")
list(FIND LLVM_AVAILABLE_LIBS LLVMXRay XRAY_INDEX)
set(COMPILER_RT_HAS_LLVMXRAY TRUE)
if (XRAY_INDEX EQUAL -1)
message(WARNING "LLVMXRay not found in LLVM_AVAILABLE_LIBS")
[XRay] Clean up XRay build configuration Summary: This change spans both LLVM and compiler-rt, where we do the following: - Add XRay to the LLVMBuild system, to allow for distributing the XRay trace loading library along with the LLVM distributions. - Use `llvm-config` better in the compiler-rt XRay implementation, to depend on the potentially already-distributed LLVM XRay library. While this is tested with the standalone compiler-rt build, it does require that the LLVMXRay library (and LLVMSupport as well) are available during the build. In case the static libraries are available, the unit tests will build and work fine. We're still having issues with attempting to use a shared library version of the LLVMXRay library since the shared library might not be accessible from the standard shared library lookup paths. The larger change here is the inclusion of the LLVMXRay library in the distribution, which allows for building tools around the XRay traces and profiles that the XRay runtime already generates. Reviewers: echristo, beanz Subscribers: mgorny, hiraditya, mboerger, llvm-commits Differential Revision: https://reviews.llvm.org/D52349 llvm-svn: 342859
2018-09-24 05:28:01 +00:00
set(COMPILER_RT_HAS_LLVMXRAY FALSE)
endif()
[compiler-rt] Switch from llvm-config to find_package(LLVM) Replace the use of the deprecated `llvm-config` tool with LLVM's CMake files for detecting LLVM in standalone builds. Differential Revision: https://reviews.llvm.org/D137024
2022-10-29 19:03:37 +02:00
list(FIND LLVM_AVAILABLE_LIBS LLVMTestingSupport TESTINGSUPPORT_INDEX)
set(COMPILER_RT_HAS_LLVMTESTINGSUPPORT TRUE)
if (TESTINGSUPPORT_INDEX EQUAL -1)
message(WARNING "LLVMTestingSupport not found in LLVM_AVAILABLE_LIBS")
set(COMPILER_RT_HAS_LLVMTESTINGSUPPORT FALSE)
Revert "[compiler-rt] Switch from llvm-config to find_package(LLVM)" This reverts commit 37acf9bdd4686397a6d37000e8d3fe35f456a860. It broke a buildbot.
2022-11-01 05:49:24 +01:00
endif()
endif()
[compiler-rt] Switch from llvm-config to find_package(LLVM) Replace the use of the deprecated `llvm-config` tool with LLVM's CMake files for detecting LLVM in standalone builds. Differential Revision: https://reviews.llvm.org/D137024
2022-10-29 19:03:37 +02:00
[compiler-rt] Switch from llvm-config to find_package(LLVM) Replace the use of the deprecated `llvm-config` tool with LLVM's CMake files for detecting LLVM in standalone builds. Differential Revision: https://reviews.llvm.org/D137024
2022-10-29 19:03:37 +02:00
set(LLVM_LIBRARY_OUTPUT_INTDIR
${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
[CMake][Compiler-rt] Compute `LLVM_MAIN_SRC_DIR` assuming the monorepo layout. When doing a standalone compiler-rt build we currently rely on getting information from the `llvm-config` binary. Previously we would rely on calling `llvm-config --src-root` to find the LLVM sources. Unfortunately the returned path could easily be wrong if the sources were built on another machine. Now that compiler-rt is part of a monorepo we can easily fix this problem by finding the LLVM source tree next to `compiler-rt` in the monorepo. We do this regardless of whether or not the `llvm-config` binary is available which moves us one step closer to not requiring `llvm-config` to be available. To try avoid anyone breaking anyone who relies on the current behavior, if the path assuming the monorepo layout doesn't exist we invoke `llvm-config --src-root` to get the path. A deprecation warning is emitted if this path is taken because we should remove this path in the future given that other runtimes already assume the monorepo layout. We also now emit a warning if `LLVM_MAIN_SRC_DIR` does not exist. The intention is that this should be a hard error in future but to avoid breaking existing users we'll keep this as a warning for now. rdar://76016632 Differential Revision: https://reviews.llvm.org/D99620
2021-03-30 12:50:59 -07:00
set(LLVM_MAIN_SRC_DIR "${LLVM_MAIN_SRC_DIR_DEFAULT}" CACHE PATH "Path to LLVM source tree")
message(STATUS "LLVM_MAIN_SRC_DIR: \"${LLVM_MAIN_SRC_DIR}\"")
if (NOT EXISTS "${LLVM_MAIN_SRC_DIR}")
# TODO(dliew): Make this a hard error
message(WARNING "LLVM_MAIN_SRC_DIR (${LLVM_MAIN_SRC_DIR}) does not exist. "
"You can override the inferred path by adding "
"`-DLLVM_MAIN_SRC_DIR=<path_to_llvm_src>` to your CMake invocation "
"where `<path_to_llvm_src>` is the path to the `llvm` directory in "
"the `llvm-project` repo. "
"This will be treated as error in the future.")
endif()
[CMake][Compiler-rt] Make it possible to configure standalone compiler-rt without `LLVMConfig.cmake`. Previously it wasn't possible to configure a standalone compiler-rt build if the `LLVMConfig.cmake` file isn't present in a shipped toolchain. This patch adds a fallback behaviour for when `LLVMConfig.cmake` is not available in the toolchain being used for configure. The fallback behaviour mocks out the bare minimum required to make a configure succeed when the host is Darwin. Support for other platforms could be added in future patches. The new code path is taken either in one of the following cases: * `llvm-config` is not available. * `llvm-config` is available but it provides an invalid path for the CMake files. The motivation here is to be able to generate the compiler-rt lit test suites for an arbitrary LLVM toolchain and then run the tests against it. The invocation to do this looks something like. ``` CC=/path/to/cc \ CXX=/path/to/c++ \ cmake \ -G Ninja \ -DLLVM_CONFIG_PATH=/path/to/llvm-config \ -DCOMPILER_RT_INCLUDE_TESTS=ON \ /path/to/llvm-project/compiler-rt # Note we don't compile compiler-rt in this workflow. bin/llvm-lit -v test/path/to/generated/test_suite ``` A possible alternative approach is to configure the `cmake/modules/LLVMConfig.cmake.in` file in the LLVM source tree and then include it. This approach was not taken because it is more complicated. An interesting side benefit of this patch is that it is now possible to configure on Darwin without `llvm-config` being available by configuring with `-DLLVM_CONFIG_PATH=""`. This moves us a step closer to a world where no LLVM build artefacts are required to build compiler-rt. rdar://76016632 Differential Revision: https://reviews.llvm.org/D99621
2021-03-30 13:47:07 -07:00
[compiler-rt] Switch from llvm-config to find_package(LLVM) Replace the use of the deprecated `llvm-config` tool with LLVM's CMake files for detecting LLVM in standalone builds. Differential Revision: https://reviews.llvm.org/D137024
2022-10-29 19:03:37 +02:00
if (NOT LLVM_FOUND)
[CMake][Compiler-rt] Make it possible to configure standalone compiler-rt without `LLVMConfig.cmake`. Previously it wasn't possible to configure a standalone compiler-rt build if the `LLVMConfig.cmake` file isn't present in a shipped toolchain. This patch adds a fallback behaviour for when `LLVMConfig.cmake` is not available in the toolchain being used for configure. The fallback behaviour mocks out the bare minimum required to make a configure succeed when the host is Darwin. Support for other platforms could be added in future patches. The new code path is taken either in one of the following cases: * `llvm-config` is not available. * `llvm-config` is available but it provides an invalid path for the CMake files. The motivation here is to be able to generate the compiler-rt lit test suites for an arbitrary LLVM toolchain and then run the tests against it. The invocation to do this looks something like. ``` CC=/path/to/cc \ CXX=/path/to/c++ \ cmake \ -G Ninja \ -DLLVM_CONFIG_PATH=/path/to/llvm-config \ -DCOMPILER_RT_INCLUDE_TESTS=ON \ /path/to/llvm-project/compiler-rt # Note we don't compile compiler-rt in this workflow. bin/llvm-lit -v test/path/to/generated/test_suite ``` A possible alternative approach is to configure the `cmake/modules/LLVMConfig.cmake.in` file in the LLVM source tree and then include it. This approach was not taken because it is more complicated. An interesting side benefit of this patch is that it is now possible to configure on Darwin without `llvm-config` being available by configuring with `-DLLVM_CONFIG_PATH=""`. This moves us a step closer to a world where no LLVM build artefacts are required to build compiler-rt. rdar://76016632 Differential Revision: https://reviews.llvm.org/D99621
2021-03-30 13:47:07 -07:00
# This configuration tries to configure without the prescence of `LLVMConfig.cmake`. It is
# intended for testing purposes (generating the lit test suites) and will likely not support
# a build of the runtimes in compiler-rt.
include(CompilerRTMockLLVMCMakeConfig)
compiler_rt_mock_llvm_cmake_config()
endif()
[CMake] Load LLVMConfig for standalone build of builtins Therefore move some code into reusable macros. Differential Revision: https://reviews.llvm.org/D22866 llvm-svn: 277418
2016-08-02 05:51:05 +00:00
endmacro()
macro(construct_compiler_rt_default_triple)
[compiler-rt] Support building builtins for a single target This is used when building builtins for multiple targets as part of LLVM runtimes. Differential Revision: https://reviews.llvm.org/D26653 llvm-svn: 289489
2016-12-12 23:14:02 +00:00
if(COMPILER_RT_DEFAULT_TARGET_ONLY)
if(DEFINED COMPILER_RT_DEFAULT_TARGET_TRIPLE)
message(FATAL_ERROR "COMPILER_RT_DEFAULT_TARGET_TRIPLE isn't supported when building for default target only")
endif()
[compiler-rt] Check for missing CMAKE_C_COMPILER_TARGET when using COMPILER_RT_DEFAULT_TARGET_ONLY COMPILER_RT_DEFAULT_TARGET_ONLY is the goto workaround for building only one of a multilib setup while still being able to autodetect the native target. For example only building 64 bit libraries on Intel instead of 32 and 64 bit. Which may fail without 32 bit compatibility libs installed. As reported in https://discourse.llvm.org/t/configuring-compiler-rt-to-use-default-target-only-does-not-work/62727 this build config hasn't worked in a while. It relies on a variable usually set during cross compliation, though my testing shows you can set it in other scenarios too. https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_TARGET.html So the options you need to provide are: -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON -DCMAKE_C_COMPILER_TARGET="aarch64-unknown-linux-gnu" And we should error if CMAKE_C_COMPILER_TARGET isn't set. Reviewed By: glaubitz Differential Revision: https://reviews.llvm.org/D147598
2023-04-05 09:00:54 +00:00
if ("${CMAKE_C_COMPILER_TARGET}" STREQUAL "")
Typo fix
2023-05-02 10:31:37 +02:00
message(FATAL_ERROR "CMAKE_C_COMPILER_TARGET must also be set when COMPILER_RT_DEFAULT_TARGET_ONLY is ON")
[compiler-rt] Check for missing CMAKE_C_COMPILER_TARGET when using COMPILER_RT_DEFAULT_TARGET_ONLY COMPILER_RT_DEFAULT_TARGET_ONLY is the goto workaround for building only one of a multilib setup while still being able to autodetect the native target. For example only building 64 bit libraries on Intel instead of 32 and 64 bit. Which may fail without 32 bit compatibility libs installed. As reported in https://discourse.llvm.org/t/configuring-compiler-rt-to-use-default-target-only-does-not-work/62727 this build config hasn't worked in a while. It relies on a variable usually set during cross compliation, though my testing shows you can set it in other scenarios too. https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_TARGET.html So the options you need to provide are: -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON -DCMAKE_C_COMPILER_TARGET="aarch64-unknown-linux-gnu" And we should error if CMAKE_C_COMPILER_TARGET isn't set. Reviewed By: glaubitz Differential Revision: https://reviews.llvm.org/D147598
2023-04-05 09:00:54 +00:00
endif()
message(STATUS "cmake c compiler target: ${CMAKE_C_COMPILER_TARGET}")
Revert "CompilerRT: Normalize COMPILER_RT_DEFAULT_TARGET_TRIPLE" (#88663) Reverts llvm/llvm-project#88407
2024-04-15 00:12:42 +08:00
set(COMPILER_RT_DEFAULT_TARGET_TRIPLE ${CMAKE_C_COMPILER_TARGET})
[compiler-rt] Support building builtins for a single target This is used when building builtins for multiple targets as part of LLVM runtimes. Differential Revision: https://reviews.llvm.org/D26653 llvm-svn: 289489
2016-12-12 23:14:02 +00:00
else()
Revert "CompilerRT: Normalize COMPILER_RT_DEFAULT_TARGET_TRIPLE" (#88663) Reverts llvm/llvm-project#88407
2024-04-15 00:12:42 +08:00
set(COMPILER_RT_DEFAULT_TARGET_TRIPLE ${LLVM_TARGET_TRIPLE} CACHE STRING
"Default triple for which compiler-rt runtimes will be built.")
[compiler-rt] Support building builtins for a single target This is used when building builtins for multiple targets as part of LLVM runtimes. Differential Revision: https://reviews.llvm.org/D26653 llvm-svn: 289489
2016-12-12 23:14:02 +00:00
endif()
[CMake] Use Clang to infer the target triple (#89425) When using Clang as a compiler, use Clang to normalize the triple that's used to construct path for runtime library build and install paths. This ensures that paths are consistent and avoids the issue where the build uses a different triple spelling. Differential Revision: https://reviews.llvm.org/D140925
2024-07-05 22:56:15 -07:00
if(CMAKE_C_COMPILER_ID MATCHES "Clang")
[compiler-rt] Fix CMake configure on Windows (#90843) CMake configure compiler-rt got broken as a result of following commit: d3925e65a7ab88eb0ba68d3ab79cd95db5629951 This patch fixes the break by porting the above commit for clang-cl. This problem was not caught on Windows buildbots beacuase it appeared when compiler-rt was included via LLVM_ENABLE_PROJECTS while buildbots include compiler-rt project using LLVM_ENABLE_RUNTIMES flag.
2024-05-02 18:27:23 +05:00
set(option_prefix "")
if (CMAKE_C_SIMULATE_ID MATCHES "MSVC")
set(option_prefix "/clang:")
endif()
[CMake] Use Clang to infer the target triple (#89425) When using Clang as a compiler, use Clang to normalize the triple that's used to construct path for runtime library build and install paths. This ensures that paths are consistent and avoids the issue where the build uses a different triple spelling. Differential Revision: https://reviews.llvm.org/D140925
2024-07-05 22:56:15 -07:00
set(print_target_triple ${CMAKE_C_COMPILER} ${option_prefix}--target=${COMPILER_RT_DEFAULT_TARGET_TRIPLE} ${option_prefix}-print-target-triple)
execute_process(COMMAND ${print_target_triple}
RESULT_VARIABLE result
OUTPUT_VARIABLE output
OUTPUT_STRIP_TRAILING_WHITESPACE)
if(result EQUAL 0)
set(COMPILER_RT_DEFAULT_TARGET_TRIPLE ${output})
else()
string(REPLACE ";" " " print_target_triple "${print_target_triple}")
# TODO(#97876): Report an error.
message(WARNING "Failed to execute `${print_target_triple}` to normalize target triple.")
endif()
CompilerRT: Normalize COMPILER_RT_DEFAULT_TARGET_TRIPLE (#89234) If LLVM is configured with -DLLVM_DEFAULT_TARGET_TRIPLE, or compiler_rt is configured with -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE, while the argument is not normalized, such as Debian-style vendor-less triple, clang will try to find libclang_rt in lib/<normalized_triple>, while libclang_rt is placed into lib/<triple_arg>. Let's also place libclang_rt into lib/<normalized_triple>. `libcxx/utils/ci/run-buildbot` is also updated to use `armv7m-none-unknown-eabi` as normalized triple instead of current `armv7m-none-eabi`. ChangeLog of this PR: This patch has been applied and revert twice: 1. The first try is https://github.com/llvm/llvm-project/pull/88407, and then it is found that it causes some CI failures. https://lab.llvm.org/buildbot/#/builders/98/builds/36366 It is then resolved by another commit: https://github.com/llvm/llvm-project/commit/1693009679313282afbed38778dd3fad62641e1b https://lab.llvm.org/buildbot/#/builders/77/builds/36372 It is caused that `COMPILER_RT_DEFAULT_TARGET_TRIPLE` is overwrite without taking care about `CACHE`. 2. The second try https://github.com/llvm/llvm-project/pull/88835, resolves https://lab.llvm.org/buildbot/#/builders/77/builds/36372 and in fact only one `execute_process` is needed. Then we find some other CI failures. https://github.com/mstorsjo/llvm-mingw/actions/runs/8730621159 https://buildkite.com/llvm-project/libcxx-ci/builds/34897#018eec06-612c-47f1-9931-d3bd88bf7ced It is due to misunderstanding `-print-effective-triple`: which will output `thumbv7-w64-windows-gnu` for `armv7-w64-windows-gnu` or some other thumb-enabled arm triples. In fact we should use `-print-target-triple`. For armv7m-picolibc, `armv7m-none-eabi` is hardcoded in libcxx/utils/ci/run-buildbot, while in fact `armv7m-none-unknown-eabi` is the real normalized triple.
2024-04-19 11:19:36 +08:00
endif()
[CMake] Rename TARGET_TRIPLE to LLVM_TARGET_TRIPLE This clarifies that this is an LLVM specific variable and avoids potential conflicts with other projects. Differential Revision: https://reviews.llvm.org/D119918
2021-12-02 01:04:46 -08:00
string(REPLACE "-" ";" LLVM_TARGET_TRIPLE_LIST ${COMPILER_RT_DEFAULT_TARGET_TRIPLE})
list(GET LLVM_TARGET_TRIPLE_LIST 0 COMPILER_RT_DEFAULT_TARGET_ARCH)
[compiler-rt] Normalize i?86 to i386 and armv* to arm for COMPILER_RT_DEFAULT_TARGET_ARCH This corresponds to getArchNameForCompilerRTLib in clang; any 32 bit x86 architecture triple (except on android, but those exceptions are already handled in compiler-rt on a different level) get the compiler rt library names with i386; arm targets get either "arm" or "armhf". (Mapping to "armhf" is handled in the toplevel CMakeLists.txt.) Differential Revision: https://reviews.llvm.org/D98173
2021-03-08 13:38:52 +02:00
# Map various forms of the architecture names to the canonical forms
# (as they are used by clang, see getArchNameForCompilerRTLib).
if("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "^i.86$")
# Android uses i686, but that's remapped at a later stage.
set(COMPILER_RT_DEFAULT_TARGET_ARCH "i386")
endif()
[compiler-rt] Initial support for builtins on GPU targets (#95304) Summary: This patch adds initial support to build the `builtins` library for GPU targets. Primarily this requires adding a few new architectures for `amdgcn` and `nvptx64`. I built this using the following invocations. ```console $ cmake ../compiler-rt -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Release -GNinja -DCMAKE_C_COMPILER_TARGET=<nvptx64-nvidia-cuda|amdgcn-amd-amdhsa> -DCMAKE_CXX_COMPILER_TARGET=<nvptx64-nvidia-cuda|amdgcn-amd-amdhsa> -DCMAKE_C_COMPILER_WORKS=1 -DCMAKE_CXX_COMPILER_WORKS=1 -DLLVM_CMAKE_DIR=../cmake/Modules -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON -C ../compiler-rt/cmake/caches/GPU.cmake ``` Some pointers would be appreciated for how to test this using a standard (non-default target only) build. GPU builds are somewhat finnicky. We only expect this to be built with a sufficiently new clang, as it's the only compiler that supports the target and output we distribute. Distribution is done as LLVM-IR blobs for now. GPUs have little backward compatibility, so linking object files is left to a future patch. More work is necessary to build correctly for all targets and ship into the correct clang resource directory. Additionally we need to use the `libc` project's support for running unit tests.
2024-07-10 15:07:11 -05:00
# If we are directly targeting a GPU we need to check that the compiler is
# compatible and pass some default arguments.
if(COMPILER_RT_DEFAULT_TARGET_ONLY)
# Pass the necessary flags to make flag detection work.
if("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "amdgcn")
set(COMPILER_RT_GPU_BUILD ON)
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -nogpulib")
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "nvptx")
set(COMPILER_RT_GPU_BUILD ON)
set(CMAKE_REQUIRED_FLAGS
"${CMAKE_REQUIRED_FLAGS} -flto -c -Wno-unused-command-line-argument")
endif()
endif()
[CMake] Load LLVMConfig for standalone build of builtins Therefore move some code into reusable macros. Differential Revision: https://reviews.llvm.org/D22866 llvm-svn: 277418
2016-08-02 05:51:05 +00:00
# Determine if test target triple is specified explicitly, and doesn't match the
# default.
[CMake] Rename TARGET_TRIPLE to LLVM_TARGET_TRIPLE This clarifies that this is an LLVM specific variable and avoids potential conflicts with other projects. Differential Revision: https://reviews.llvm.org/D119918
2021-12-02 01:04:46 -08:00
if(NOT COMPILER_RT_DEFAULT_TARGET_TRIPLE STREQUAL LLVM_TARGET_TRIPLE)
[CMake] Load LLVMConfig for standalone build of builtins Therefore move some code into reusable macros. Differential Revision: https://reviews.llvm.org/D22866 llvm-svn: 277418
2016-08-02 05:51:05 +00:00
set(COMPILER_RT_HAS_EXPLICIT_DEFAULT_TARGET_TRIPLE TRUE)
else()
set(COMPILER_RT_HAS_EXPLICIT_DEFAULT_TARGET_TRIPLE FALSE)
endif()
endmacro()
[builtins] Prevent duplicate definitions for overridden functions Summary: Some architecture-specific function overrides (for example, i386/ashrdi3.S) duplicate generic functions (in that case, ashrdi3.c). Prevent duplicate definitions by filtering out the generic files before compiling. Reviewers: compnerd, beanz Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D37166 llvm-svn: 312140
2017-08-30 17:12:57 +00:00
[builtins] Cleanup generic-file filtering Split filter_builtin_sources into two functions: - filter_builtin_sources that removes generic files when an arch-specific file is selected. - darwin_filter_builtin_sources that implements the EXCLUDE/INCLUDE lists (using the files in lib/builtins/Darwin-excludes). darwin_filter_builtin_sources delegates to filter_builtin_sources. Previously, lib/builtins/CMakeLists.txt had a number of calls to filter_builtin_sources (with a confusing/broken use of the `excluded_list` parameter), as well as a redundant arch-vs-generic filtering for the non-Apple code path at the end of the file. Replace all of this with a single call to filter_builtin_sources. Remove i686_SOURCES. Previously, this list contained only the arch-specific files common to 32-bit and 64-bit x86, which is a strange set. Normally the ${ARCH}_SOURCES list contains everything needed for the arch. "i686" isn't in ALL_BUILTIN_SUPPORTED_ARCH. NFCI, but i686_SOURCES won't be defined, and the order of files in ${arch}_SOURCES lists will change. Differential Revision: https://reviews.llvm.org/D82151
2020-06-18 23:59:36 -07:00
# Filter out generic versions of routines that are re-implemented in an
# architecture specific manner. This prevents multiple definitions of the same
# symbols, making the symbol selection non-deterministic.
#
# We follow the convention that a source file that exists in a sub-directory
# (e.g. `ppc/divtc3.c`) is architecture-specific and that if a generic
# implementation exists it will be a top-level source file with the same name
# modulo the file extension (e.g. `divtc3.c`).
function(filter_builtin_sources inout_var name)
set(intermediate ${${inout_var}})
foreach(_file ${intermediate})
get_filename_component(_file_dir ${_file} DIRECTORY)
if (NOT "${_file_dir}" STREQUAL "")
# Architecture specific file. If a generic version exists, print a notice
# and ensure that it is removed from the file list.
[builtins] Prevent duplicate definitions for overridden functions Summary: Some architecture-specific function overrides (for example, i386/ashrdi3.S) duplicate generic functions (in that case, ashrdi3.c). Prevent duplicate definitions by filtering out the generic files before compiling. Reviewers: compnerd, beanz Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D37166 llvm-svn: 312140
2017-08-30 17:12:57 +00:00
get_filename_component(_name ${_file} NAME)
[builtins] Cleanup generic-file filtering Split filter_builtin_sources into two functions: - filter_builtin_sources that removes generic files when an arch-specific file is selected. - darwin_filter_builtin_sources that implements the EXCLUDE/INCLUDE lists (using the files in lib/builtins/Darwin-excludes). darwin_filter_builtin_sources delegates to filter_builtin_sources. Previously, lib/builtins/CMakeLists.txt had a number of calls to filter_builtin_sources (with a confusing/broken use of the `excluded_list` parameter), as well as a redundant arch-vs-generic filtering for the non-Apple code path at the end of the file. Replace all of this with a single call to filter_builtin_sources. Remove i686_SOURCES. Previously, this list contained only the arch-specific files common to 32-bit and 64-bit x86, which is a strange set. Normally the ${ARCH}_SOURCES list contains everything needed for the arch. "i686" isn't in ALL_BUILTIN_SUPPORTED_ARCH. NFCI, but i686_SOURCES won't be defined, and the order of files in ${arch}_SOURCES lists will change. Differential Revision: https://reviews.llvm.org/D82151
2020-06-18 23:59:36 -07:00
string(REGEX REPLACE "\\.S$" ".c" _cname "${_name}")
if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/${_cname}")
message(STATUS "For ${name} builtins preferring ${_file} to ${_cname}")
list(REMOVE_ITEM intermediate ${_cname})
endif()
endif()
endforeach()
set(${inout_var} ${intermediate} PARENT_SCOPE)
[builtins] Prevent duplicate definitions for overridden functions Summary: Some architecture-specific function overrides (for example, i386/ashrdi3.S) duplicate generic functions (in that case, ashrdi3.c). Prevent duplicate definitions by filtering out the generic files before compiling. Reviewers: compnerd, beanz Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D37166 llvm-svn: 312140
2017-08-30 17:12:57 +00:00
endfunction()
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 03:11:52 +00:00
function(get_compiler_rt_target arch variable)
[CMake] Don't parse target triple except for arch compiler-rt CMake build currently tries to parse the triple and then put it back together, but doing so inherently tricky, and doing so from CMake is just crazy and currently doesn't handle triples that have more than three components. Fortunatelly, the CMake really only needs the architecture part, which is typically the first component, to construct variants for other architectures. This means we can keep the rest of the triple as is and avoid the parsing altogether. Differential Revision: https://reviews.llvm.org/D50548 llvm-svn: 339701
2018-08-14 18:01:19 +00:00
string(FIND ${COMPILER_RT_DEFAULT_TARGET_TRIPLE} "-" dash_index)
string(SUBSTRING ${COMPILER_RT_DEFAULT_TARGET_TRIPLE} ${dash_index} -1 triple_suffix)
[CMake] Fix MIPSr6 build for compiler-rt The current version pass -mips64r2 or -mips32r2 options, which make it failed to build on r6 platform. In this patch: we detect whether we are MIPSr6 by _MIPS_ARCH_MIPS32R6/_MIPS_ARCH_MIPS64R6 The out and install path is set to the default triple instead of hardcoded one, since the clang ask for it. Differential Revision: https://reviews.llvm.org/D135735
2022-10-18 04:49:25 +00:00
string(SUBSTRING ${COMPILER_RT_DEFAULT_TARGET_TRIPLE} 0 ${dash_index} triple_cpu)
[compiler-rt] Use exact spelling when building for default target When building for default target only, use exact target spelling when deriving the name for the per-target runtime directory. This is necessary for AArch32 where the CMake build by default rewrites the architecture which leads to unexpected results. Differential Revision: https://reviews.llvm.org/D54612 llvm-svn: 347022
2018-11-16 04:14:23 +00:00
if(COMPILER_RT_DEFAULT_TARGET_ONLY)
# Use exact spelling when building only for the target specified to CMake.
set(target "${COMPILER_RT_DEFAULT_TARGET_TRIPLE}")
elseif(ANDROID AND ${arch} STREQUAL "i386")
[builtins][Android] Fix 386->686 adjustment At this point in this code: - COMPILER_RT_DEFAULT_TARGET_TRIPLE is "i686-linux-android" - arch is "i386" The get_compiler_rt_target function currently turns that into: i686-android-linux-android The ${COMPILER_RT_OS_SUFFIX} is "-android" and redundant, so stop adding it. The get_compiler_rt_target() function is used for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR mode that isn't normally used with Android. Differential Revision: https://reviews.llvm.org/D82150
2020-06-18 23:57:08 -07:00
set(target "i686${triple_suffix}")
[compiler-rt] Handle non-canonical triples with new runtime lib layout As described in Issue #54196 <https://github.com/llvm/llvm-project/issues/54196>, the ideas of `clang` and `compiler-rt` where runtime libs are located with `-DLLVM_ENABLE_RUNTIMES` can differ. This is the `compiler-rt` side of the patch I've used to get them in sync for the `amd64-pc-solaris2.11` and `sparc64-unknown-linux-gnu` release builds. Tested on `amd64-pc-solaris2.11` and `sparc64-unknown-linux-gnu`. Differential Revision: https://reviews.llvm.org/D133406
2022-09-11 11:25:53 +02:00
elseif(${arch} STREQUAL "amd64")
set(target "x86_64${triple_suffix}")
elseif(${arch} STREQUAL "sparc64")
set(target "sparcv9${triple_suffix}")
[CMake] Fix MIPSr6 build for compiler-rt The current version pass -mips64r2 or -mips32r2 options, which make it failed to build on r6 platform. In this patch: we detect whether we are MIPSr6 by _MIPS_ARCH_MIPS32R6/_MIPS_ARCH_MIPS64R6 The out and install path is set to the default triple instead of hardcoded one, since the clang ask for it. Differential Revision: https://reviews.llvm.org/D135735
2022-10-18 04:49:25 +00:00
elseif("${arch}" MATCHES "mips64|mips64el")
string(REGEX REPLACE "-gnu.*" "-gnuabi64" triple_suffix_gnu "${triple_suffix}")
string(REGEX REPLACE "mipsisa32" "mipsisa64" triple_cpu_mips "${triple_cpu}")
string(REGEX REPLACE "^mips$" "mips64" triple_cpu_mips "${triple_cpu_mips}")
string(REGEX REPLACE "^mipsel$" "mips64el" triple_cpu_mips "${triple_cpu_mips}")
set(target "${triple_cpu_mips}${triple_suffix_gnu}")
elseif("${arch}" MATCHES "mips|mipsel")
string(REGEX REPLACE "-gnuabi.*" "-gnu" triple_suffix_gnu "${triple_suffix}")
string(REGEX REPLACE "mipsisa64" "mipsisa32" triple_cpu_mips "${triple_cpu}")
string(REGEX REPLACE "mips64" "mips" triple_cpu_mips "${triple_cpu_mips}")
set(target "${triple_cpu_mips}${triple_suffix_gnu}")
[clang][compiler-rt] Support LLVM_ENABLE_PER_TARGET_RUNTIME_DIR on Arm Linux and BSD The orginal single folder layout produced libraries in the form: lib/linux/<libname>-<archname>.a That archname for Arm depended on whether you had hard or soft float. This is sometimes shown as "arm" (soft) vs. "armhf" (hard). If this is set in a triple we do it in the final portion, the ABI. "gnueabi" for soft float, "gnueabihf" for hard float. Meaning that the expected triple is: arm-unknown-linux-gnueabihf Not this: armhf-unknown-linux-gnueabihf For the per target layout I have decided to rely on the ABI portion of the triple instead of the arch name used for the old layout (doing that would produce the invalid triple above). This means that building with triple: armv8l-unknown-linux-gnueabihf Will result in libraries in: lib/arm-unknown-linux-gnueabihf/ And clang will now know to look for "arm" instead of "armv8l". Meaning that we can share libraries between an armv8 and armv7 build as we did with the previous layout. In addition to handling spelling differences e.g. "armv8l" with an "l" on some Linux distros. compiler-rt will autodetect that the "armhf" and/or "arm" architecture can be built. We then replace the given triple's architecture with that. Then if the triple's float ABI doesn't match, we change that. That new triple is then used as the folder name. If you select to build only the given triple, with COMPILER_RT_DEFAULT_TARGET_ONLY, compiler-rt will not autodetect the architecture and for that I assume you know what you're doing. In that case the library path will use the unomdified triple. From what I can tell, this is how most large builds e.g Android and Arm's Embedded Toolchain for llvm do things. I assume that big endian "armeb" builds would end up doing this too. Bare metal builds will not be using per target runtime dirs so they remain as they were. Depends on D139536 Reviewed By: MaskRay, phosek Differential Revision: https://reviews.llvm.org/D140011
2022-12-01 14:54:17 +00:00
elseif("${arch}" MATCHES "^arm")
# Arch is arm, armhf, armv6m (anything else would come from using
# COMPILER_RT_DEFAULT_TARGET_ONLY, which is checked above).
if (${arch} STREQUAL "armhf")
# If we are building for hard float but our ABI is soft float.
if ("${triple_suffix}" MATCHES ".*eabi$")
# Change "eabi" -> "eabihf"
set(triple_suffix "${triple_suffix}hf")
endif()
# ABI is already set in the triple, don't repeat it in the architecture.
set(arch "arm")
else ()
# If we are building for soft float, but the triple's ABI is hard float.
if ("${triple_suffix}" MATCHES ".*eabihf$")
# Change "eabihf" -> "eabi"
string(REGEX REPLACE "hf$" "" triple_suffix "${triple_suffix}")
endif()
endif()
set(target "${arch}${triple_suffix}")
[compiler-rt] Initial support for builtins on GPU targets (#95304) Summary: This patch adds initial support to build the `builtins` library for GPU targets. Primarily this requires adding a few new architectures for `amdgcn` and `nvptx64`. I built this using the following invocations. ```console $ cmake ../compiler-rt -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Release -GNinja -DCMAKE_C_COMPILER_TARGET=<nvptx64-nvidia-cuda|amdgcn-amd-amdhsa> -DCMAKE_CXX_COMPILER_TARGET=<nvptx64-nvidia-cuda|amdgcn-amd-amdhsa> -DCMAKE_C_COMPILER_WORKS=1 -DCMAKE_CXX_COMPILER_WORKS=1 -DLLVM_CMAKE_DIR=../cmake/Modules -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON -C ../compiler-rt/cmake/caches/GPU.cmake ``` Some pointers would be appreciated for how to test this using a standard (non-default target only) build. GPU builds are somewhat finnicky. We only expect this to be built with a sufficiently new clang, as it's the only compiler that supports the target and output we distribute. Distribution is done as LLVM-IR blobs for now. GPUs have little backward compatibility, so linking object files is left to a future patch. More work is necessary to build correctly for all targets and ship into the correct clang resource directory. Additionally we need to use the `libc` project's support for running unit tests.
2024-07-10 15:07:11 -05:00
elseif("${arch}" MATCHES "^amdgcn")
set(target "amdgcn-amd-amdhsa")
elseif("${arch}" MATCHES "^nvptx")
set(target "nvptx64-nvidia-cuda")
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 03:11:52 +00:00
else()
[CMake] Don't parse target triple except for arch compiler-rt CMake build currently tries to parse the triple and then put it back together, but doing so inherently tricky, and doing so from CMake is just crazy and currently doesn't handle triples that have more than three components. Fortunatelly, the CMake really only needs the architecture part, which is typically the first component, to construct variants for other architectures. This means we can keep the rest of the triple as is and avoid the parsing altogether. Differential Revision: https://reviews.llvm.org/D50548 llvm-svn: 339701
2018-08-14 18:01:19 +00:00
set(target "${arch}${triple_suffix}")
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 03:11:52 +00:00
endif()
set(${variable} ${target} PARENT_SCOPE)
endfunction()
function(get_compiler_rt_install_dir arch install_dir)
if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
get_compiler_rt_target(${arch} target)
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-28 22:36:47 +00:00
set(${install_dir} ${COMPILER_RT_INSTALL_LIBRARY_DIR}/${target} PARENT_SCOPE)
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 03:11:52 +00:00
else()
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-28 22:36:47 +00:00
set(${install_dir} ${COMPILER_RT_INSTALL_LIBRARY_DIR} PARENT_SCOPE)
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 03:11:52 +00:00
endif()
endfunction()
function(get_compiler_rt_output_dir arch output_dir)
if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
get_compiler_rt_target(${arch} target)
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-28 22:36:47 +00:00
set(${output_dir} ${COMPILER_RT_OUTPUT_LIBRARY_DIR}/${target} PARENT_SCOPE)
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 03:11:52 +00:00
else()
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-28 22:36:47 +00:00
set(${output_dir} ${COMPILER_RT_OUTPUT_LIBRARY_DIR} PARENT_SCOPE)
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 03:11:52 +00:00
endif()
endfunction()
[CMake] Add compiler-rt header files to the list of sources for targets when building with an IDE so that header files show up in the UI. This massively improves the development workflow in IDEs. To implement this a new function `compiler_rt_process_sources(...)` has been added that adds header files to the list of sources when the generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no changes are made to the list of source files. The function can be passed a list of headers via the `ADDITIONAL_HEADERS` argument. For each runtime library a list of explicit header files has been added and passed via `ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of headers was already present but it was stale and has been updated to reflect the current state of the source tree. The original version of this patch used file globbing (`*.{h,inc,def}`) to find the headers but the approach was changed due to this being a CMake anti-pattern (if the list of headers changes CMake won't automatically re-generate if globbing is used). The LLVM repo contains a similar function named `llvm_process_sources()` but we don't use it here for several reasons: * It depends on the `LLVM_ENABLE_OPTION` cache variable which is not set in standalone compiler-rt builds. * We would have to `include(LLVMProcessSources)` which I'd like to avoid because it would include a bunch of stuff we don't need. Differential Revision: https://reviews.llvm.org/D48422 llvm-svn: 336663
2018-07-10 13:00:17 +00:00
# compiler_rt_process_sources(
# <OUTPUT_VAR>
# <SOURCE_FILE> ...
# [ADDITIONAL_HEADERS <header> ...]
# )
#
# Process the provided sources and write the list of new sources
# into `<OUTPUT_VAR>`.
#
# ADDITIONAL_HEADERS - Adds the supplied header to list of sources for IDEs.
#
# This function is very similar to `llvm_process_sources()` but exists here
# because we need to support standalone builds of compiler-rt.
function(compiler_rt_process_sources OUTPUT_VAR)
cmake_parse_arguments(
ARG
""
""
"ADDITIONAL_HEADERS"
${ARGN}
)
set(sources ${ARG_UNPARSED_ARGUMENTS})
set(headers "")
if (XCODE OR MSVC_IDE OR CMAKE_EXTRA_GENERATOR)
# For IDEs we need to tell CMake about header files.
# Otherwise they won't show up in UI.
set(headers ${ARG_ADDITIONAL_HEADERS})
list(LENGTH headers headers_length)
if (${headers_length} GREATER 0)
set_source_files_properties(${headers}
PROPERTIES HEADER_FILE_ONLY ON)
endif()
endif()
set("${OUTPUT_VAR}" ${sources} ${headers} PARENT_SCOPE)
endfunction()
[compiler-rt] Create install targets for Darwin libraries Darwin targets were generating CMake install rules but not the corresponding install targets. Centralize the existing install target creation to a function and use that function for both Darwin and non-Darwin builds. Differential Revision: https://reviews.llvm.org/D61541 llvm-svn: 360181
2019-05-07 19:00:37 +00:00
# Create install targets for a library and its parent component (if specified).
function(add_compiler_rt_install_targets name)
cmake_parse_arguments(ARG "" "PARENT_TARGET" "" ${ARGN})
if(ARG_PARENT_TARGET AND NOT TARGET install-${ARG_PARENT_TARGET})
# The parent install target specifies the parent component to scrape up
# anything not installed by the individual install targets, and to handle
# installation when running the multi-configuration generators.
add_custom_target(install-${ARG_PARENT_TARGET}
DEPENDS ${ARG_PARENT_TARGET}
COMMAND "${CMAKE_COMMAND}"
-DCMAKE_INSTALL_COMPONENT=${ARG_PARENT_TARGET}
-P "${CMAKE_BINARY_DIR}/cmake_install.cmake")
add_custom_target(install-${ARG_PARENT_TARGET}-stripped
DEPENDS ${ARG_PARENT_TARGET}
COMMAND "${CMAKE_COMMAND}"
-DCMAKE_INSTALL_COMPONENT=${ARG_PARENT_TARGET}
-DCMAKE_INSTALL_DO_STRIP=1
-P "${CMAKE_BINARY_DIR}/cmake_install.cmake")
set_target_properties(install-${ARG_PARENT_TARGET} PROPERTIES
[compiler-rt] Revise IDE folder structure (#89753) Update the folder titles for targets in the monorepository that have not seen taken care of for some time. These are the folders that targets are organized in Visual Studio and XCode (`set_property(TARGET <target> PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE generator. * Ensure that every target is in a folder * Use a folder hierarchy with each LLVM subproject as a top-level folder * Use consistent folder names between subprojects * When using target-creating functions from AddLLVM.cmake, automatically deduce the folder. This reduces the number of `set_property`/`set_target_property`, but are still necessary when `add_custom_target`, `add_executable`, `add_library`, etc. are used. A LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's root CMakeLists.txt.
2024-06-04 09:26:45 +02:00
FOLDER "Compiler-RT/Installation")
[compiler-rt] Create install targets for Darwin libraries Darwin targets were generating CMake install rules but not the corresponding install targets. Centralize the existing install target creation to a function and use that function for both Darwin and non-Darwin builds. Differential Revision: https://reviews.llvm.org/D61541 llvm-svn: 360181
2019-05-07 19:00:37 +00:00
set_target_properties(install-${ARG_PARENT_TARGET}-stripped PROPERTIES
[compiler-rt] Revise IDE folder structure (#89753) Update the folder titles for targets in the monorepository that have not seen taken care of for some time. These are the folders that targets are organized in Visual Studio and XCode (`set_property(TARGET <target> PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE generator. * Ensure that every target is in a folder * Use a folder hierarchy with each LLVM subproject as a top-level folder * Use consistent folder names between subprojects * When using target-creating functions from AddLLVM.cmake, automatically deduce the folder. This reduces the number of `set_property`/`set_target_property`, but are still necessary when `add_custom_target`, `add_executable`, `add_library`, etc. are used. A LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's root CMakeLists.txt.
2024-06-04 09:26:45 +02:00
FOLDER "Compiler-RT/Installation")
[compiler-rt] Create install targets for Darwin libraries Darwin targets were generating CMake install rules but not the corresponding install targets. Centralize the existing install target creation to a function and use that function for both Darwin and non-Darwin builds. Differential Revision: https://reviews.llvm.org/D61541 llvm-svn: 360181
2019-05-07 19:00:37 +00:00
add_dependencies(install-compiler-rt install-${ARG_PARENT_TARGET})
add_dependencies(install-compiler-rt-stripped install-${ARG_PARENT_TARGET}-stripped)
endif()
# We only want to generate per-library install targets if you aren't using
# an IDE because the extra targets get cluttered in IDEs.
if(NOT CMAKE_CONFIGURATION_TYPES)
add_custom_target(install-${name}
DEPENDS ${name}
COMMAND "${CMAKE_COMMAND}"
-DCMAKE_INSTALL_COMPONENT=${name}
-P "${CMAKE_BINARY_DIR}/cmake_install.cmake")
add_custom_target(install-${name}-stripped
DEPENDS ${name}
COMMAND "${CMAKE_COMMAND}"
-DCMAKE_INSTALL_COMPONENT=${name}
-DCMAKE_INSTALL_DO_STRIP=1
-P "${CMAKE_BINARY_DIR}/cmake_install.cmake")
# If you have a parent target specified, we bind the new install target
# to the parent install target.
if(LIB_PARENT_TARGET)
add_dependencies(install-${LIB_PARENT_TARGET} install-${name})
add_dependencies(install-${LIB_PARENT_TARGET}-stripped install-${name}-stripped)
endif()
endif()
endfunction()
[compiler-rt][builtins] Add compiler flags to catch potential errors that can lead to security vulnerabilities Also, fix a few places that were causing -Wshadow and -Wformat-nonliteral warnings to be emitted. This reapplies the patch that was reverted in caaafe4ae250 because it broke Fuchsia builders. I reverted the changes I made to InstrProfData.inc and instead renamed the variables in InstrProfilingWriter.c. Also fixed a bug in function add_security_warnings that was causing it to pass -Wformat-nonliteral when the compiler doesn't support it.
2022-08-25 21:34:09 -07:00
# Add warnings to catch potential errors that can lead to security
# vulnerabilities.
function(add_security_warnings out_flags macosx_sdk_version)
set(flags "${${out_flags}}")
append_list_if(COMPILER_RT_HAS_ARRAY_BOUNDS_FLAG -Werror=array-bounds flags)
append_list_if(COMPILER_RT_HAS_UNINITIALIZED_FLAG -Werror=uninitialized flags)
append_list_if(COMPILER_RT_HAS_SHADOW_FLAG -Werror=shadow flags)
append_list_if(COMPILER_RT_HAS_EMPTY_BODY_FLAG -Werror=empty-body flags)
append_list_if(COMPILER_RT_HAS_SIZEOF_POINTER_MEMACCESS_FLAG -Werror=sizeof-pointer-memaccess flags)
append_list_if(COMPILER_RT_HAS_SIZEOF_ARRAY_ARGUMENT_FLAG -Werror=sizeof-array-argument flags)
[compiler-rt][builtins] Enable more warnings in add_security_warnings Enable -Wsizeof-array-div and -Wsizeof-pointer-divcompiler. Also, replace -Wmemset-transposed-args with -Wsuspicious-memaccess. The latter automatically enables the former and a few other warnings. Differential Revision: https://reviews.llvm.org/D133783
2022-09-13 08:47:43 -07:00
append_list_if(COMPILER_RT_HAS_SUSPICIOUS_MEMACCESS_FLAG -Werror=suspicious-memaccess flags)
[compiler-rt][builtins] Add compiler flags to catch potential errors that can lead to security vulnerabilities Also, fix a few places that were causing -Wshadow and -Wformat-nonliteral warnings to be emitted. This reapplies the patch that was reverted in caaafe4ae250 because it broke Fuchsia builders. I reverted the changes I made to InstrProfData.inc and instead renamed the variables in InstrProfilingWriter.c. Also fixed a bug in function add_security_warnings that was causing it to pass -Wformat-nonliteral when the compiler doesn't support it.
2022-08-25 21:34:09 -07:00
append_list_if(COMPILER_RT_HAS_BUILTIN_MEMCPY_CHK_SIZE_FLAG -Werror=builtin-memcpy-chk-size flags)
append_list_if(COMPILER_RT_HAS_ARRAY_BOUNDS_POINTER_ARITHMETIC_FLAG -Werror=array-bounds-pointer-arithmetic flags)
append_list_if(COMPILER_RT_HAS_RETURN_STACK_ADDRESS_FLAG -Werror=return-stack-address flags)
append_list_if(COMPILER_RT_HAS_SIZEOF_ARRAY_DECAY_FLAG -Werror=sizeof-array-decay flags)
append_list_if(COMPILER_RT_HAS_FORMAT_INSUFFICIENT_ARGS_FLAG -Werror=format-insufficient-args flags)
[compiler-rt] Unbreak GCC builds after bfa6444a332f82843 GCC complains if we pass -Werror=format-security without -Wformat. Reported at https://github.com/llvm/llvm-project/pull/83779#issuecomment-1985246797
2024-03-08 00:45:02 -08:00
# GCC complains if we pass -Werror=format-security without -Wformat
append_list_if(COMPILER_RT_HAS_BUILTIN_FORMAL_SECURITY_FLAG -Wformat -Werror=format-security flags)
[compiler-rt][builtins] Enable more warnings in add_security_warnings Enable -Wsizeof-array-div and -Wsizeof-pointer-divcompiler. Also, replace -Wmemset-transposed-args with -Wsuspicious-memaccess. The latter automatically enables the former and a few other warnings. Differential Revision: https://reviews.llvm.org/D133783
2022-09-13 08:47:43 -07:00
append_list_if(COMPILER_RT_HAS_SIZEOF_ARRAY_DIV_FLAG -Werror=sizeof-array-div)
append_list_if(COMPILER_RT_HAS_SIZEOF_POINTER_DIV_FLAG -Werror=sizeof-pointer-div)
[compiler-rt][builtins] Add compiler flags to catch potential errors that can lead to security vulnerabilities Also, fix a few places that were causing -Wshadow and -Wformat-nonliteral warnings to be emitted. This reapplies the patch that was reverted in caaafe4ae250 because it broke Fuchsia builders. I reverted the changes I made to InstrProfData.inc and instead renamed the variables in InstrProfilingWriter.c. Also fixed a bug in function add_security_warnings that was causing it to pass -Wformat-nonliteral when the compiler doesn't support it.
2022-08-25 21:34:09 -07:00
# Add -Wformat-nonliteral only if we can avoid adding the definition of
# eprintf. On Apple platforms, eprintf is needed only on macosx and only if
# its version is older than 10.7.
if ("${macosx_sdk_version}" VERSION_GREATER_EQUAL 10.7)
list(APPEND flags -Werror=format-nonliteral -DDONT_DEFINE_EPRINTF)
endif()
set(${out_flags} "${flags}" PARENT_SCOPE)
endfunction()
Reference in New Issue Copy Permalink