mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-16 11:26:42 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/compiler-rt/lib/builtins/CMakeLists.txt

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

1010 lines
26 KiB
CMake
Raw Normal View History

Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
# This directory contains a large amount of C code which provides
# generic implementations of the core runtime library along with optimized
# architecture-specific code in various subdirectories.
[CMake] Support platform building builtins without a full toolchain Summary: This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake. This patch contains the following specific changes: * Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake * Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake * Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64. This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653. Reviewers: samsonov, iains, jroelofs Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D19742 llvm-svn: 268977
2016-05-09 21:45:52 +00:00
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
Reland "[CMake] Bumps minimum version to 3.20.0. This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6. Adds the patch by @hans from https://github.com/llvm/llvm-project/issues/62719 This patch fixes the Windows build. d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews D144509 [CMake] Bumps minimum version to 3.20.0. This partly undoes D137724. This change has been discussed on discourse https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193 Note this does not remove work-arounds for older CMake versions, that will be done in followup patches. D150532 [OpenMP] Compile assembly files as ASM, not C Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent) when compiling a file which has been set as having the language C. This behaviour change only takes place if "cmake_minimum_required" is set to 3.20 or newer, or if the policy CMP0119 is set to new. Attempting to compile assembly files with "-x c" fails, however this is workarounded in many cases, as OpenMP overrides this with "-x assembler-with-cpp", however this is only added for non-Windows targets. Thus, after increasing cmake_minimum_required to 3.20, this breaks compiling the GNU assembly for Windows targets; the GNU assembly is used for ARM and AArch64 Windows targets when building with Clang. This patch unbreaks that. D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump The build uses other mechanism to select the runtime. Fixes #62719 Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D151344
2023-05-24 18:12:32 +02:00
cmake_minimum_required(VERSION 3.20.0)
[CMake] Support platform building builtins without a full toolchain Summary: This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake. This patch contains the following specific changes: * Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake * Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake * Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64. This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653. Reviewers: samsonov, iains, jroelofs Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D19742 llvm-svn: 268977
2016-05-09 21:45:52 +00:00
Revert "compiler-rt: Fix FLOAT16 feature detection" This reverts commit aaa93ce7323332d8290b8f563d4d71689c1094c5. This commit was not properly reviewed.
2024-01-24 12:38:09 -08:00
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
[CMake] Support platform building builtins without a full toolchain Summary: This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake. This patch contains the following specific changes: * Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake * Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake * Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64. This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653. Reviewers: samsonov, iains, jroelofs Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D19742 llvm-svn: 268977
2016-05-09 21:45:52 +00:00
project(CompilerRTBuiltins C ASM)
set(COMPILER_RT_STANDALONE_BUILD TRUE)
set(COMPILER_RT_BUILTINS_STANDALONE_BUILD TRUE)
[CMake] Use `LLVM_COMMON_CMAKE_UTILS` in runtimes just for clarity In D116472 we created conditionally defined variables for the tools to unbreak the legacy build where they are in `llvm/tools`. The runtimes are not tools, so that flexibility doesn't matter. Still, it might be nice to define (unconditionally) and use the variable for the runtimes simply to make the code a bit clearer and document what is going on. Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path. Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116477
2022-01-01 07:03:31 +00:00
set(COMPILER_RT_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../..")
set(LLVM_COMMON_CMAKE_UTILS "${COMPILER_RT_SOURCE_DIR}/../cmake")
# Add path for custom modules
[CMake] Support platform building builtins without a full toolchain Summary: This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake. This patch contains the following specific changes: * Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake * Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake * Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64. This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653. Reviewers: samsonov, iains, jroelofs Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D19742 llvm-svn: 268977
2016-05-09 21:45:52 +00:00
list(INSERT CMAKE_MODULE_PATH 0
[CMake] Use `LLVM_COMMON_CMAKE_UTILS` in runtimes just for clarity In D116472 we created conditionally defined variables for the tools to unbreak the legacy build where they are in `llvm/tools`. The runtimes are not tools, so that flexibility doesn't matter. Still, it might be nice to define (unconditionally) and use the variable for the runtimes simply to make the code a bit clearer and document what is going on. Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path. Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116477
2022-01-01 07:03:31 +00:00
"${COMPILER_RT_SOURCE_DIR}/cmake"
"${COMPILER_RT_SOURCE_DIR}/cmake/Modules"
"${LLVM_COMMON_CMAKE_UTILS}"
"${LLVM_COMMON_CMAKE_UTILS}/Modules"
)
[CMake] Support platform building builtins without a full toolchain Summary: This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake. This patch contains the following specific changes: * Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake * Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake * Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64. This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653. Reviewers: samsonov, iains, jroelofs Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D19742 llvm-svn: 268977
2016-05-09 21:45:52 +00:00
include(base-config-ix)
include(CompilerRTUtils)
[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
[CMake][compiler-rt] Don't load LLVM config in the runtimes build LLVM runtimes build already loads the LLVM config and sets all appropriate variables, no need to do it again. Differential Revision: https://reviews.llvm.org/D137870
2022-11-11 22:50:14 +00:00
if (NOT LLVM_RUNTIMES_BUILD)
load_llvm_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
construct_compiler_rt_default_triple()
[CMake] Move the AIX archiver settings to a module This allows their reuse across projects. The name of the module is intentionally generic because we would like to move more platform checks there. Differential Revision: https://reviews.llvm.org/D115276
2021-12-07 11:53:38 -08:00
include(SetPlatformToolchainTools)
[CMake] Support platform building builtins without a full toolchain Summary: This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake. This patch contains the following specific changes: * Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake * Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake * Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64. This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653. Reviewers: samsonov, iains, jroelofs Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D19742 llvm-svn: 268977
2016-05-09 21:45:52 +00:00
if(APPLE)
include(CompilerRTDarwinUtils)
endif()
[runtimes] Use llvm-libtool-darwin for runtimes build It's full featured now and we can use it for the runtimes build instead of relying on an external libtool, which means the CMAKE_HOST_APPLE restriction serves no purpose either now. Restrict llvm-lipo to Darwin targets while I'm here, since it's only needed there. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D86367
2020-08-21 13:03:13 -07:00
if(APPLE)
[builtins] Use libtool for builtins when building for Apple platform compiler-rt already uses libtool instead of ar when building for Apple platform, but that's not being used when builtins are being built separately e.g. as part of the runtimes build. This change extracts the logic setting up libtool into a separate file and uses it from both the compiler-rt and standalone builtins build. Differential Revision: https://reviews.llvm.org/D62820 llvm-svn: 362466
2019-06-04 02:38:15 +00:00
include(UseLibtool)
endif()
[CMake] Support platform building builtins without a full toolchain Summary: This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake. This patch contains the following specific changes: * Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake * Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake * Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64. This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653. Reviewers: samsonov, iains, jroelofs Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D19742 llvm-svn: 268977
2016-05-09 21:45:52 +00:00
include(AddCompilerRT)
[compiler-rt] Fix linking a standalone libatomic for MinGW (#74668) Whenever linking with -nodefaultlibs for a MinGW target, we manually need to specify a bunch of libraries - listed in ${MINGW_LIBRARIES}; the same is already done for sanitizers and libunwind/libcxxabi/libcxx. Practically speaking, linking with -nodefaultlibs but manually passing the libraries in ${MINGW_LIBRARIES} restores most of the libraries that are linked by default, except for the potential compiler builtins and unwind library; i.e. it has essentially the same effect as linking with "--unwindlib=none -rtlib=none", except that -rtlib doesn't accept such a value. When building only compiler-rt/lib/builtins, not all of compiler-rt, ${MINGW_LIBRARIES} is unset - set it manually here for that case. This matches what is set in compiler-rt/cmake/config-ix.cmake, except that the builtins (libgcc or compiler-rt builtins) is omitted; the only use within lib/buitlins is for the standalone libatomic, which explicitly already links against the just-built builtins.
2023-12-07 13:25:24 +02:00
if(MINGW)
# Simplified version of what's set in cmake/config-ix.cmake; not including
# builtins, which are linked separately.
set(MINGW_LIBRARIES mingw32 moldname mingwex msvcrt advapi32 shell32
user32 kernel32 mingw32 moldname mingwex msvcrt)
endif()
[CMake] Support platform building builtins without a full toolchain Summary: This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake. This patch contains the following specific changes: * Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake * Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake * Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64. This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653. Reviewers: samsonov, iains, jroelofs Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D19742 llvm-svn: 268977
2016-05-09 21:45:52 +00:00
endif()
[CMake] compiler-rt: Add COMPILER_RT_BUILTINS_ENABLE_PIC The configuration for -fPIC in the builtins library when built standalone is unconditional, stating that the flags would "normally be added... by the llvm cmake step" This is untrue, as the llvm cmake step checks LLVM_ENABLE_PIC, which allows a client to turn off -fPIC. I've added an option when compiler-rt builtins are configured standalone, such as when built as part of the LLVM runtimes system, to guard the application of -fPIC for users that want it. Patch By: JamesNagurne Differential Revision: https://reviews.llvm.org/D72950
2020-01-31 15:57:18 -08:00
if (COMPILER_RT_STANDALONE_BUILD)
# When compiler-rt is being built standalone, possibly as a cross-compilation
# target, the target may or may not want position independent code. This
# option provides an avenue through which the flag may be controlled when an
# LLVM configuration is not being utilized.
option(COMPILER_RT_BUILTINS_ENABLE_PIC
"Turns on or off -fPIC for the builtin library source"
ON)
endif()
[CMake] Support platform building builtins without a full toolchain Summary: This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake. This patch contains the following specific changes: * Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake * Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake * Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64. This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653. Reviewers: samsonov, iains, jroelofs Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D19742 llvm-svn: 268977
2016-05-09 21:45:52 +00:00
include(builtin-config-ix)
[compiler-rt] Move crt into builtins On Linux crt is typically use in combination with builtins. In the Clang driver the use of builtins and crt is controlled by the --rtlib option. Both builtins and crt also have similar build requirements where they need to be built before any other runtimes and must avoid dependencies. We also want builtins and crt these to be buildable separately from the rest of compiler-rt for bootstrapping purposes. Given how simple crt is, rather than maintaining a separate directory with its own separate build setup, it's more efficient to just move crt into builtins. We still use separate CMake option to control whether to built crt same as before. This is an alternative to D89492 and D136664. Differential Revision: https://reviews.llvm.org/D153989
2023-06-28 07:14:00 +00:00
include(CMakeDependentOption)
[builtins] Only build float16/bfloat16 code if actually supported When building compiler-rt builtins for x86_64 they library will by default also be built for i386. We unconditionally add the Float16 compile flags since the check for Float16 support will be done using x86_64 compiler flags, but i386 does not actually support it. Fix this by moving the COMPILER_RT_HAS_FLOAT16 and COMPILER_RT_HAS_FLOAT16 checks to a per-target-architecture check inside the loop (using `check_c_source_compiles` and `cmake_{push,pop}_check_state`). Many of the checks in the builtin-config-ix file should probably also be changed to per-target-arch checks, but so far only the Float16 one has caused issues. This is an alternative to D136044 which added a special case for i386 FreeBSD. Fixes: https://github.com/llvm/llvm-project/issues/57224 Differential Revision: https://reviews.llvm.org/D145237
2023-03-03 13:54:08 +00:00
include(CMakePushCheckState)
[CMake] Support platform building builtins without a full toolchain Summary: This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake. This patch contains the following specific changes: * Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake * Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake * Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64. This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653. Reviewers: samsonov, iains, jroelofs Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D19742 llvm-svn: 268977
2016-05-09 21:45:52 +00:00
[builtins] Add COMPILER_RT_BUILTINS_HIDE_SYMBOLS On Android, when the builtins are linked into a binary, they are typically linked using -Wl,--exclude-libs so that the symbols aren't reexported. For the NDK, compiler-rt's default behavior (build the builtins archive with -fvisibility=hidden) is better so that builtins are hidden even without -Wl,--exclude-libs. Android needs the builtins with non-hidden symbols only for a special case: for backwards compatibility with old binaries, the libc.so and libm.so DSOs in the platform need to export some builtins for arm32 and 32-bit x86. See D56977. Control the behavior with a new flag, `COMPILER_RT_BUILTINS_HIDE_SYMBOLS`, that behaves similarly to the `*_HERMETIC_STATIC_LIBRARY` in libunwind/libcxx/libcxxabi, so that Android can build a special builtins variant for libc.so/libm.so. Unlike the hermetic flags for other projects, this new flag is enabled by default. Reviewed By: compnerd, MaskRay Differential Revision: https://reviews.llvm.org/D93431
2021-01-07 17:49:29 -08:00
option(COMPILER_RT_BUILTINS_HIDE_SYMBOLS
"Do not export any symbols from the static library." ON)
[CMake] Actually adding the TODO comment I mentioned in r252927. Turns out you need to save before committing. llvm-svn: 252928
2015-11-12 19:17:05 +00:00
# TODO: Need to add a mechanism for logging errors when builtin source files are
# added to a sub-directory and not this CMakeLists file.
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
set(GENERIC_SOURCES
absvdi2.c
absvsi2.c
absvti2.c
adddf3.c
addsf3.c
addvdi3.c
addvsi3.c
addvti3.c
apple_versioning.c
ashldi3.c
ashlti3.c
ashrdi3.c
ashrti3.c
Add generic __bswap[ds]i2 implementations Summary: In FreeBSD we needed to add generic implementations for `__bswapdi2` and `__bswapsi2`, since gcc 6.x for mips is emitting calls to these. See: https://reviews.freebsd.org/D10838 and https://reviews.freebsd.org/rS318601 The actual mips code generated for these generic C versions is pretty OK, as can be seen in the (FreeBSD) review. I checked over gcc sources, and it seems that it can emit these calls on more architectures, so maybe it's best to simply always add them to the compiler-rt builtins library. Reviewers: howard.hinnant, compnerd, petarj, emaste Reviewed By: compnerd, emaste Subscribers: mgorny, llvm-commits, arichardson Differential Revision: https://reviews.llvm.org/D33516 llvm-svn: 303866
2017-05-25 14:52:14 +00:00
bswapdi2.c
bswapsi2.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
clzdi2.c
clzsi2.c
clzti2.c
cmpdi2.c
cmpti2.c
comparedf2.c
comparesf2.c
ctzdi2.c
ctzsi2.c
ctzti2.c
divdc3.c
divdf3.c
divdi3.c
divmoddi4.c
divmodsi4.c
Add __divmodti4 to match libgcc. gcc has used this on x86-64 since at least version 7. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D80506
2020-09-16 21:56:01 -07:00
divmodti4.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
divsc3.c
divsf3.c
divsi3.c
divti3.c
extendsfdf2.c
[Builtins] Implement half-precision conversions. Mostly uninteresting, except: - in __extendXfYf2, when checking if the number is normal, the old code relied on the unsignedness of src_rep_t, which is a problem when sizeof(src_rep_t) < sizeof(int): the result gets promoted to int, the signedness of which breaks the comparison. I added an explicit cast; it shouldn't affect other types. - we can't pass __fp16, so src_t and src_rep_t are the same. - the gnu_*_ieee symbols are simply duplicated definitions, as aliases are problematic on mach-o (where only weak aliases are supported; that's not what we want). Differential Revision: http://reviews.llvm.org/D9693 llvm-svn: 237161
2015-05-12 18:33:42 +00:00
extendhfsf2.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
ffsdi2.c
Add __ffssi2 implementation to compiler-rt builtins Summary: During MIPS implementation work for FreeBSD, John Baldwin (jhb@FreeBSD.org) found that gcc 6.x emits calls to __ffssi2() when compiling libc and some userland programs in the base system. Add it to compiler-rt's builtins, based off of the existing __ffsdi2() implementation. Also update the CMake files and add a test case. Reviewers: howard.hinnant, weimingz, rengolin, compnerd Reviewed By: weimingz Subscribers: dberris, mgorny, llvm-commits, emaste Differential Revision: https://reviews.llvm.org/D31721 llvm-svn: 299675
2017-04-06 18:12:02 +00:00
ffssi2.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
ffsti2.c
fixdfdi.c
fixdfsi.c
fixdfti.c
fixsfdi.c
fixsfsi.c
fixsfti.c
fixunsdfdi.c
fixunsdfsi.c
fixunsdfti.c
fixunssfdi.c
fixunssfsi.c
fixunssfti.c
floatdidf.c
floatdisf.c
floatsidf.c
floatsisf.c
floattidf.c
floattisf.c
floatundidf.c
floatundisf.c
floatunsidf.c
floatunsisf.c
floatuntidf.c
floatuntisf.c
Revert "Revert "[builtins] Rounding mode support for addxf3/subxf3"" Test failure fixed. This reverts commit e204d244badb2e9765a1020f41c773f63da208f4. llvm-svn: 371003
2019-09-05 01:05:05 +00:00
fp_mode.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
int_util.c
lshrdi3.c
lshrti3.c
moddi3.c
modsi3.c
modti3.c
muldc3.c
muldf3.c
muldi3.c
mulodi4.c
mulosi4.c
muloti4.c
mulsc3.c
mulsf3.c
multi3.c
mulvdi3.c
mulvsi3.c
mulvti3.c
negdf2.c
negdi2.c
negsf2.c
negti2.c
negvdi2.c
negvsi2.c
negvti2.c
Reapply r297382: "[compiler-rt][builtins] Add __isOSVersionAtLeast()" Looks like the problem was a case-insensitive include of dispatch/dispatch.h. llvm-svn: 297392
2017-03-09 17:02:16 +00:00
os_version_check.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
paritydi2.c
paritysi2.c
parityti2.c
popcountdi2.c
popcountsi2.c
popcountti2.c
powidf2.c
powisf2.c
subdf3.c
subsf3.c
subvdi3.c
subvsi3.c
subvti3.c
trampoline_setup.c
[Builtins] Implement half-precision conversions. Mostly uninteresting, except: - in __extendXfYf2, when checking if the number is normal, the old code relied on the unsignedness of src_rep_t, which is a problem when sizeof(src_rep_t) < sizeof(int): the result gets promoted to int, the signedness of which breaks the comparison. I added an explicit cast; it shouldn't affect other types. - we can't pass __fp16, so src_t and src_rep_t are the same. - the gnu_*_ieee symbols are simply duplicated definitions, as aliases are problematic on mach-o (where only weak aliases are supported; that's not what we want). Differential Revision: http://reviews.llvm.org/D9693 llvm-svn: 237161
2015-05-12 18:33:42 +00:00
truncdfhf2.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
truncdfsf2.c
[Builtins] Implement half-precision conversions. Mostly uninteresting, except: - in __extendXfYf2, when checking if the number is normal, the old code relied on the unsignedness of src_rep_t, which is a problem when sizeof(src_rep_t) < sizeof(int): the result gets promoted to int, the signedness of which breaks the comparison. I added an explicit cast; it shouldn't affect other types. - we can't pass __fp16, so src_t and src_rep_t are the same. - the gnu_*_ieee symbols are simply duplicated definitions, as aliases are problematic on mach-o (where only weak aliases are supported; that's not what we want). Differential Revision: http://reviews.llvm.org/D9693 llvm-svn: 237161
2015-05-12 18:33:42 +00:00
truncsfhf2.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
ucmpdi2.c
ucmpti2.c
udivdi3.c
udivmoddi4.c
udivmodsi4.c
udivmodti4.c
udivsi3.c
udivti3.c
umoddi3.c
umodsi3.c
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
umodti3.c
)
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
[builtins] Only build float16/bfloat16 code if actually supported When building compiler-rt builtins for x86_64 they library will by default also be built for i386. We unconditionally add the Float16 compile flags since the check for Float16 support will be done using x86_64 compiler flags, but i386 does not actually support it. Fix this by moving the COMPILER_RT_HAS_FLOAT16 and COMPILER_RT_HAS_FLOAT16 checks to a per-target-architecture check inside the loop (using `check_c_source_compiles` and `cmake_{push,pop}_check_state`). Many of the checks in the builtin-config-ix file should probably also be changed to per-target-arch checks, but so far only the Float16 one has caused issues. This is an alternative to D136044 which added a special case for i386 FreeBSD. Fixes: https://github.com/llvm/llvm-project/issues/57224 Differential Revision: https://reviews.llvm.org/D145237
2023-03-03 13:54:08 +00:00
# We only build BF16 files when "__bf16" is available.
set(BF16_SOURCES
[SelectionDAG] Add `STRICT_BF16_TO_FP` and `STRICT_FP_TO_BF16` (#80056) This patch adds the support for `STRICT_BF16_TO_FP` and `STRICT_FP_TO_BF16`.
2024-03-04 00:01:50 -05:00
extendbfsf2.c
Revert "[compiler-rt][builtins] Skip building (b)float16 support on i386-freebsd" This reverts commit 45368c75582f0bded1f06d5c82c1f2ee023fb186. There were some unexpected failures in aarch64 and arm buildbots, I will have to investigate why these suddenly fell over.
2023-01-23 11:21:28 +01:00
truncdfbf2.c
Reland "[X86][BF16] Add libcall for F80 -> BF16 (#109116)" (#109143) This reverts commit ababfee78714313a0cad87591b819f0944b90d09. Add X86 FP80 check.
2024-09-19 15:39:07 +08:00
truncxfbf2.c
Revert "[compiler-rt][builtins] Skip building (b)float16 support on i386-freebsd" This reverts commit 45368c75582f0bded1f06d5c82c1f2ee023fb186. There were some unexpected failures in aarch64 and arm buildbots, I will have to investigate why these suddenly fell over.
2023-01-23 11:21:28 +01:00
truncsfbf2.c
[X86][BF16] Add libcall for FP128 -> BF16 (#115825) This is to fix #115710.
2024-11-12 15:54:09 +08:00
trunctfbf2.c
[builtins] Only build float16/bfloat16 code if actually supported When building compiler-rt builtins for x86_64 they library will by default also be built for i386. We unconditionally add the Float16 compile flags since the check for Float16 support will be done using x86_64 compiler flags, but i386 does not actually support it. Fix this by moving the COMPILER_RT_HAS_FLOAT16 and COMPILER_RT_HAS_FLOAT16 checks to a per-target-architecture check inside the loop (using `check_c_source_compiles` and `cmake_{push,pop}_check_state`). Many of the checks in the builtin-config-ix file should probably also be changed to per-target-arch checks, but so far only the Float16 one has caused issues. This is an alternative to D136044 which added a special case for i386 FreeBSD. Fixes: https://github.com/llvm/llvm-project/issues/57224 Differential Revision: https://reviews.llvm.org/D145237
2023-03-03 13:54:08 +00:00
)
[compiler-rt][BF16] Provide __truncdfbf2 and __truncsfbf2 only when __bf16 is available Differential Revision: https://reviews.llvm.org/D131147
2022-08-10 09:13:27 +08:00
[compiler-rt][mips] Add support for quad precision builtins for mips64 Match the builtins that GCC provides for IEEE754 quad precision on MIPS64. Also, enable building them with clang as PR20098 is resolved. Disable tests for xf and xc modes as MIPS doesn't support that mode in hardware or software. Reviewers: slthakur Differential Revision: https://reviews.llvm.org/D32794 llvm-svn: 302147
2017-05-04 13:34:17 +00:00
set(GENERIC_TF_SOURCES
[builtins] Move more float128-related helpers to GENERIC_TF_SOURCES list There are two different _generic_ lists of source files in the compiler-rt/lib/builtins/CMakeLists.txt. Now there is no simple way to not use the tf-variants of helpers at all. Since there exists a separate `GENERIC_TF_SOURCES` list, it seems quite natural to move all float128-related helpers there. If it is not possible for some reason, it would be useful to have an explanation of that reason somewhere near the `GENERIC_TF_SOURCES` definition. Differential Revision: https://reviews.llvm.org/D81282
2020-06-25 22:32:41 +03:00
addtf3.c
[compiler-rt][mips] Add support for quad precision builtins for mips64 Match the builtins that GCC provides for IEEE754 quad precision on MIPS64. Also, enable building them with clang as PR20098 is resolved. Disable tests for xf and xc modes as MIPS doesn't support that mode in hardware or software. Reviewers: slthakur Differential Revision: https://reviews.llvm.org/D32794 llvm-svn: 302147
2017-05-04 13:34:17 +00:00
comparetf2.c
[builtins] Move more float128-related helpers to GENERIC_TF_SOURCES list There are two different _generic_ lists of source files in the compiler-rt/lib/builtins/CMakeLists.txt. Now there is no simple way to not use the tf-variants of helpers at all. Since there exists a separate `GENERIC_TF_SOURCES` list, it seems quite natural to move all float128-related helpers there. If it is not possible for some reason, it would be useful to have an explanation of that reason somewhere near the `GENERIC_TF_SOURCES` definition. Differential Revision: https://reviews.llvm.org/D81282
2020-06-25 22:32:41 +03:00
divtc3.c
divtf3.c
[compiler-rt][mips] Add support for quad precision builtins for mips64 Match the builtins that GCC provides for IEEE754 quad precision on MIPS64. Also, enable building them with clang as PR20098 is resolved. Disable tests for xf and xc modes as MIPS doesn't support that mode in hardware or software. Reviewers: slthakur Differential Revision: https://reviews.llvm.org/D32794 llvm-svn: 302147
2017-05-04 13:34:17 +00:00
extenddftf2.c
[compiler-rt] [builtins] Support conversion between fp16 and fp128 This patch adds both extendhftf2 and trunctfhf2 to support conversion between half-precision and quad-precision floating-point values. They are built iff the compiler supports _Float16. Some notes on ARM plaforms: while fp16 is supported on all architectures, _Float16 is supported only for 32-bit ARM, 64-bit ARM, and SPIR (as indicated by clang/docs/LanguageExtensions.rst). Also, fp16 is a storage format and 64-bit ARM supports floating-point convert precision to half as base armv8-a instruction. This patch does not change the ABI for 32-bit ARM, it will continue to pass _Float16 as uint16. This re-enabled revert done by https://reviews.llvm.org/rGb534beabeed3ba1777cd0ff9ce552d077e496726 Differential Revision: https://reviews.llvm.org/D92242
2020-12-08 10:26:18 -03:00
extendhftf2.c
[compiler-rt][mips] Add support for quad precision builtins for mips64 Match the builtins that GCC provides for IEEE754 quad precision on MIPS64. Also, enable building them with clang as PR20098 is resolved. Disable tests for xf and xc modes as MIPS doesn't support that mode in hardware or software. Reviewers: slthakur Differential Revision: https://reviews.llvm.org/D32794 llvm-svn: 302147
2017-05-04 13:34:17 +00:00
extendsftf2.c
fixtfdi.c
fixtfsi.c
fixtfti.c
fixunstfdi.c
fixunstfsi.c
fixunstfti.c
floatditf.c
floatsitf.c
floattitf.c
floatunditf.c
floatunsitf.c
floatuntitf.c
multc3.c
[builtins] Move more float128-related helpers to GENERIC_TF_SOURCES list There are two different _generic_ lists of source files in the compiler-rt/lib/builtins/CMakeLists.txt. Now there is no simple way to not use the tf-variants of helpers at all. Since there exists a separate `GENERIC_TF_SOURCES` list, it seems quite natural to move all float128-related helpers there. If it is not possible for some reason, it would be useful to have an explanation of that reason somewhere near the `GENERIC_TF_SOURCES` definition. Differential Revision: https://reviews.llvm.org/D81282
2020-06-25 22:32:41 +03:00
multf3.c
powitf2.c
subtf3.c
[compiler-rt][mips] Add support for quad precision builtins for mips64 Match the builtins that GCC provides for IEEE754 quad precision on MIPS64. Also, enable building them with clang as PR20098 is resolved. Disable tests for xf and xc modes as MIPS doesn't support that mode in hardware or software. Reviewers: slthakur Differential Revision: https://reviews.llvm.org/D32794 llvm-svn: 302147
2017-05-04 13:34:17 +00:00
trunctfdf2.c
[compiler-rt] [builtins] Support conversion between fp16 and fp128 This patch adds both extendhftf2 and trunctfhf2 to support conversion between half-precision and quad-precision floating-point values. They are built iff the compiler supports _Float16. Some notes on ARM plaforms: while fp16 is supported on all architectures, _Float16 is supported only for 32-bit ARM, 64-bit ARM, and SPIR (as indicated by clang/docs/LanguageExtensions.rst). Also, fp16 is a storage format and 64-bit ARM supports floating-point convert precision to half as base armv8-a instruction. This patch does not change the ABI for 32-bit ARM, it will continue to pass _Float16 as uint16. This re-enabled revert done by https://reviews.llvm.org/rGb534beabeed3ba1777cd0ff9ce552d077e496726 Differential Revision: https://reviews.llvm.org/D92242
2020-12-08 10:26:18 -03:00
trunctfhf2.c
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
trunctfsf2.c
)
[compiler-rt][mips] Add support for quad precision builtins for mips64 Match the builtins that GCC provides for IEEE754 quad precision on MIPS64. Also, enable building them with clang as PR20098 is resolved. Disable tests for xf and xc modes as MIPS doesn't support that mode in hardware or software. Reviewers: slthakur Differential Revision: https://reviews.llvm.org/D32794 llvm-svn: 302147
2017-05-04 13:34:17 +00:00
[CMake] Add option (defaulted off) to exclude atomic.c The atomic builtin source is problematic when cross-compiling builtins because it requires a variable and sometimes large set of system headers. This option allows users to optionally prevent it from being built. llvm-svn: 280416
2016-09-01 21:05:49 +00:00
option(COMPILER_RT_EXCLUDE_ATOMIC_BUILTIN
[compiler-rt] [builtins] Don't build __atomic_* by default. The locks need to be implemented in a shared library to work correctly, so they shouldn't be part of libclang_rt.builtins.a, except in specialized scenarios where the user can prove it will only be linked once. Differential Revision: https://reviews.llvm.org/D47606 llvm-svn: 334779
2018-06-14 23:22:53 +00:00
"Skip the atomic builtin (these should normally be provided by a shared library)"
On)
[CMake] Add option (defaulted off) to exclude atomic.c The atomic builtin source is problematic when cross-compiling builtins because it requires a variable and sometimes large set of system headers. This option allows users to optionally prevent it from being built. llvm-svn: 280416
2016-09-01 21:05:49 +00:00
[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(NOT FUCHSIA AND NOT COMPILER_RT_BAREMETAL_BUILD AND NOT COMPILER_RT_GPU_BUILD)
[cmake] Disable building enable_execute_stack.c for baremetal targets. Disable building enable_execute_stack.c for targets that do not have support for mprotect(). Differential Revision: https://reviews.llvm.org/D33018 llvm-svn: 302680
2017-05-10 15:34:25 +00:00
set(GENERIC_SOURCES
${GENERIC_SOURCES}
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
emutls.c
[builtins] Better Fuchsia support Add Fuchsia support to some builtings and avoid building builtins that are not and will never be used on Fuchsia. Differential Revision: https://reviews.llvm.org/D34075 llvm-svn: 307832
2017-07-12 19:33:30 +00:00
enable_execute_stack.c
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
eprintf.c
)
[cmake] Disable building enable_execute_stack.c for baremetal targets. Disable building enable_execute_stack.c for targets that do not have support for mprotect(). Differential Revision: https://reviews.llvm.org/D33018 llvm-svn: 302680
2017-05-10 15:34:25 +00:00
endif()
[compiler-rt][builtins] Add opt-in pthread_mutex_t locks to libatomic (#95326) When an uninstrumented libatomic is used with a TSan instrumented memcpy, TSan may report a data race in circumstances where writes are arguably safe. This occurs because __atomic_compare_exchange won't be instrumented in an uninstrumented libatomic, so TSan doesn't know that the subsequent memcpy is race-free. On the other hand, pthread_mutex_(un)lock will be intercepted by TSan, meaning an uninstrumented libatomic will not report this false-positive. pthread_mutexes also may try a number of different strategies to acquire the lock, which may bound the amount of time a thread has to wait for a lock during contention. While pthread_mutex_lock has a larger overhead (due to the function call and some dispatching), a dispatch to libatomic already predicates a lack of performance guarantees.
2024-06-13 10:03:15 -07:00
option(COMPILER_RT_LIBATOMIC_USE_PTHREAD
"Whether libatomic should use pthreads if available."
Off)
if(COMPILER_RT_LIBATOMIC_USE_PTHREAD)
add_compile_definitions(_LIBATOMIC_USE_PTHREAD)
endif()
[CMake] Add option (defaulted off) to exclude atomic.c The atomic builtin source is problematic when cross-compiling builtins because it requires a variable and sometimes large set of system headers. This option allows users to optionally prevent it from being built. llvm-svn: 280416
2016-09-01 21:05:49 +00:00
if(COMPILER_RT_HAS_ATOMIC_KEYWORD AND NOT COMPILER_RT_EXCLUDE_ATOMIC_BUILTIN)
[CMake] If the compiler supports _Atomic include atomic.c in builtins libraries This fixes a long-standing TODO by implementing a compiler check for supporting the _Atomic keyword. If the _Atomic keyword is supported by the compiler we should include it in the builtin library sources. llvm-svn: 278454
2016-08-12 01:29:26 +00:00
set(GENERIC_SOURCES
${GENERIC_SOURCES}
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
atomic.c
)
[CMake] If the compiler supports _Atomic include atomic.c in builtins libraries This fixes a long-standing TODO by implementing a compiler check for supporting the _Atomic keyword. If the _Atomic keyword is supported by the compiler we should include it in the builtin library sources. llvm-svn: 278454
2016-08-12 01:29:26 +00:00
endif()
[CMake] [builtins] Only include the atomic builtins if(APPLE). There are lingering issues building the atomic builtins with various versions of gcc. To unblock people we can only include them on Apple platforms where they are more tested. llvm-svn: 248386
2015-09-23 15:28:44 +00:00
if(APPLE)
set(GENERIC_SOURCES
${GENERIC_SOURCES}
atomic_flag_clear.c
atomic_flag_clear_explicit.c
atomic_flag_test_and_set.c
atomic_flag_test_and_set_explicit.c
atomic_signal_fence.c
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
atomic_thread_fence.c
)
[CMake] [builtins] Only include the atomic builtins if(APPLE). There are lingering issues building the atomic builtins with various versions of gcc. To unblock people we can only include them on Apple platforms where they are more tested. llvm-svn: 248386
2015-09-23 15:28:44 +00:00
endif()
builtins: avoid duplicating unwind declarations Use unwind.h to get the declarations for unwinding interfaces. This header is already provided by clang and gcc, so this adds no additional dependencies for building the builtins library. It avoids the duplication which may drift over time though. llvm-svn: 225990
2015-01-14 15:55:17 +00:00
if (HAVE_UNWIND_H)
set(GENERIC_SOURCES
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
${GENERIC_SOURCES}
gcc_personality_v0.c
)
builtins: avoid duplicating unwind declarations Use unwind.h to get the declarations for unwinding interfaces. This header is already provided by clang and gcc, so this adds no additional dependencies for building the builtins library. It avoids the duplication which may drift over time though. llvm-svn: 225990
2015-01-14 15:55:17 +00:00
endif ()
[builtins] Better Fuchsia support Add Fuchsia support to some builtings and avoid building builtins that are not and will never be used on Fuchsia. Differential Revision: https://reviews.llvm.org/D34075 llvm-svn: 307832
2017-07-12 19:33:30 +00:00
if (NOT FUCHSIA)
set(GENERIC_SOURCES
${GENERIC_SOURCES}
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
clear_cache.c
)
[builtins] Better Fuchsia support Add Fuchsia support to some builtings and avoid building builtins that are not and will never be used on Fuchsia. Differential Revision: https://reviews.llvm.org/D34075 llvm-svn: 307832
2017-07-12 19:33:30 +00:00
endif()
[builtins] Omit 80-bit builtins on Android and MSVC long double is a 64-bit double-precision type on: - MSVC (32- and 64-bit x86) - Android (32-bit x86) long double is a 128-bit quad-precision type on x86_64 Android. The assembly variants of the 80-bit builtins are correct, but some of the builtins are implemented in C and require that long double be the 80-bit type passed via an x87 register. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D82153
2020-07-16 15:10:22 -07:00
# These files are used on 32-bit and 64-bit x86.
cmake list formatting fix
2020-07-16 18:29:48 -04:00
set(x86_ARCH_SOURCES
[builtins] Refactor cpu_model support to reduce #if nesting. NFCI Reviewers: petrhosek, DavidSpickett Pull Request: https://github.com/llvm/llvm-project/pull/75635
2023-12-19 11:09:50 -07:00
cpu_model/x86.c
cmake list formatting fix
2020-07-16 18:29:48 -04:00
)
[builtins] Omit 80-bit builtins on Android and MSVC long double is a 64-bit double-precision type on: - MSVC (32- and 64-bit x86) - Android (32-bit x86) long double is a 128-bit quad-precision type on x86_64 Android. The assembly variants of the 80-bit builtins are correct, but some of the builtins are implemented in C and require that long double be the 80-bit type passed via an x87 register. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D82153
2020-07-16 15:10:22 -07:00
if (NOT MSVC)
set(x86_ARCH_SOURCES
${x86_ARCH_SOURCES}
i386/fp_mode.c
)
endif ()
# Implement extended-precision builtins, assuming long double is 80 bits.
# long double is not 80 bits on Android or MSVC.
set(x86_80_BIT_SOURCES
Move x86-specific sources to x86-specific source lists. llvm-svn: 319464
2017-11-30 19:39:33 +00:00
divxc3.c
Add extendhfxf2 into compiler rt (#113897) Retry of pr #109090 and #111099. Co-authored-by: Alexander Richardson <alexrichardson@google.com>
2024-11-25 23:49:27 +05:30
extendhfxf2.c
[compiler-rt] Implement __extendxftf2 and __trunctfxf2 for x86_64 (#66918) This patch implements __extendxftf2 (long double -> f128) and __trunctfxf2 (f128 -> long double) on x86_64. This is a preparation to unblock https://reviews.llvm.org/D53608, We intentionally do not modify compiler-rt/lib/builtins/fp_lib.h in this PR (in particular, to limit the scope and avoid exposing other functions on X86_64 in this PR). Instead, TODOs were added to use fp_lib.h once it is available. Test plan: 1. ninja check-compiler-rt (verified on X86_64 and on Aarch64) In particular, new tests (extendxftf2_test.c and trunctfxf2_test.c) were added. 2. compared the results of conversions with what other compilers (gcc) produce.
2023-10-16 16:12:33 -07:00
extendxftf2.c
Move x86-specific sources to x86-specific source lists. llvm-svn: 319464
2017-11-30 19:39:33 +00:00
fixxfdi.c
fixxfti.c
fixunsxfdi.c
fixunsxfsi.c
fixunsxfti.c
floatdixf.c
floattixf.c
floatundixf.c
floatuntixf.c
mulxc3.c
powixf2.c
[compiler-rt] Implement __extendxftf2 and __trunctfxf2 for x86_64 (#66918) This patch implements __extendxftf2 (long double -> f128) and __trunctfxf2 (f128 -> long double) on x86_64. This is a preparation to unblock https://reviews.llvm.org/D53608, We intentionally do not modify compiler-rt/lib/builtins/fp_lib.h in this PR (in particular, to limit the scope and avoid exposing other functions on X86_64 in this PR). Instead, TODOs were added to use fp_lib.h once it is available. Test plan: 1. ninja check-compiler-rt (verified on X86_64 and on Aarch64) In particular, new tests (extendxftf2_test.c and trunctfxf2_test.c) were added. 2. compared the results of conversions with what other compilers (gcc) produce.
2023-10-16 16:12:33 -07:00
trunctfxf2.c
Add truncxfhf2 with tests to compiler-rt (#120372) Fixes #105181
2024-12-31 03:44:43 +05:30
truncxfhf2.c
Move x86-specific sources to x86-specific source lists. llvm-svn: 319464
2017-11-30 19:39:33 +00:00
)
builtins: use C implementation on MSVC The assembly implementations use GNU syntax which MSVC doesn't handle. Rather than duplicate the code in a second syntax, use the C implementations. Patch by Tee Hao Wei! llvm-svn: 250360
2015-10-15 02:47:19 +00:00
if (NOT MSVC)
compiler-rt: add support for mingw-w64 in builtins The is so that we can avoid using libgcc and use compiler-rt with mingw-w64. Related driver patch http://reviews.llvm.org/D11077 I have tested this with mingw-w64 and everything seems to be in order. I also sent this patch to the mingw-w64 mailing list for them to look at. Patch by Martell Malone. Differential Revision: http://reviews.llvm.org/D11085 llvm-svn: 242539
2015-07-17 16:23:05 +00:00
set(x86_64_SOURCES
[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
${GENERIC_SOURCES}
[builtins] Build x86_64 with GENERIC_TF_SOURCES llvm-svn: 358706
2019-04-18 19:29:03 +00:00
${GENERIC_TF_SOURCES}
[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
${x86_ARCH_SOURCES}
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
x86_64/floatdidf.c
x86_64/floatdisf.c
)
[compiler-rt] [builtins] Don't use assembly floatundi*f on x86_64 mingw The x86 assembly is entirely skipped for MSVC build configurations, since the assembly uses GAS syntax (which MSVC proper can't assemble, but clang-cl can). But for mingw configurations, the assembly is used. On x86_64 Windows, the general calling convention is entirely different than on other platforms (passing arguments in different registers), so we can't use this assembly for mingw targets (unless adapted to handle that calling convention). Thus skip these few assembly routines for Windows targets. (For i386, we can keep using the assembly functions.) This fixes the builtins tests that test these routines. They aren't used in practice though, as LLVM expands code inline for doing such conversions anyway. Differential Revision: https://reviews.llvm.org/D147685
2023-04-06 07:51:35 +00:00
if (NOT WIN32)
set(x86_64_SOURCES
${x86_64_SOURCES}
x86_64/floatundidf.S
x86_64/floatundisf.S
)
endif()
[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
[builtins] Omit 80-bit builtins on Android and MSVC long double is a 64-bit double-precision type on: - MSVC (32- and 64-bit x86) - Android (32-bit x86) long double is a 128-bit quad-precision type on x86_64 Android. The assembly variants of the 80-bit builtins are correct, but some of the builtins are implemented in C and require that long double be the 80-bit type passed via an x87 register. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D82153
2020-07-16 15:10:22 -07:00
if (NOT ANDROID)
set(x86_64_SOURCES
${x86_64_SOURCES}
${x86_80_BIT_SOURCES}
x86_64/floatdixf.c
)
[compiler-rt] [builtins] Don't use assembly floatundi*f on x86_64 mingw The x86 assembly is entirely skipped for MSVC build configurations, since the assembly uses GAS syntax (which MSVC proper can't assemble, but clang-cl can). But for mingw configurations, the assembly is used. On x86_64 Windows, the general calling convention is entirely different than on other platforms (passing arguments in different registers), so we can't use this assembly for mingw targets (unless adapted to handle that calling convention). Thus skip these few assembly routines for Windows targets. (For i386, we can keep using the assembly functions.) This fixes the builtins tests that test these routines. They aren't used in practice though, as LLVM expands code inline for doing such conversions anyway. Differential Revision: https://reviews.llvm.org/D147685
2023-04-06 07:51:35 +00:00
if (NOT WIN32)
set(x86_64_SOURCES
${x86_64_SOURCES}
x86_64/floatundixf.S
)
endif()
[builtins] Omit 80-bit builtins on Android and MSVC long double is a 64-bit double-precision type on: - MSVC (32- and 64-bit x86) - Android (32-bit x86) long double is a 128-bit quad-precision type on x86_64 Android. The assembly variants of the 80-bit builtins are correct, but some of the builtins are implemented in C and require that long double be the 80-bit type passed via an x87 register. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D82153
2020-07-16 15:10:22 -07:00
endif()
[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
# Darwin x86_64 Haswell
builtins: use C implementation on MSVC The assembly implementations use GNU syntax which MSVC doesn't handle. Rather than duplicate the code in a second syntax, use the C implementations. Patch by Tee Hao Wei! llvm-svn: 250360
2015-10-15 02:47:19 +00:00
set(x86_64h_SOURCES ${x86_64_SOURCES})
compiler-rt: add support for mingw-w64 in builtins The is so that we can avoid using libgcc and use compiler-rt with mingw-w64. Related driver patch http://reviews.llvm.org/D11077 I have tested this with mingw-w64 and everything seems to be in order. I also sent this patch to the mingw-w64 mailing list for them to look at. Patch by Martell Malone. Differential Revision: http://reviews.llvm.org/D11085 llvm-svn: 242539
2015-07-17 16:23:05 +00:00
builtins: use C implementation on MSVC The assembly implementations use GNU syntax which MSVC doesn't handle. Rather than duplicate the code in a second syntax, use the C implementations. Patch by Tee Hao Wei! llvm-svn: 250360
2015-10-15 02:47:19 +00:00
if (WIN32)
set(x86_64_SOURCES
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
${x86_64_SOURCES}
x86_64/chkstk.S
)
builtins: use C implementation on MSVC The assembly implementations use GNU syntax which MSVC doesn't handle. Rather than duplicate the code in a second syntax, use the C implementations. Patch by Tee Hao Wei! llvm-svn: 250360
2015-10-15 02:47:19 +00:00
endif()
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
compiler-rt: add support for mingw-w64 in builtins The is so that we can avoid using libgcc and use compiler-rt with mingw-w64. Related driver patch http://reviews.llvm.org/D11077 I have tested this with mingw-w64 and everything seems to be in order. I also sent this patch to the mingw-w64 mailing list for them to look at. Patch by Martell Malone. Differential Revision: http://reviews.llvm.org/D11085 llvm-svn: 242539
2015-07-17 16:23:05 +00:00
set(i386_SOURCES
[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
${GENERIC_SOURCES}
${x86_ARCH_SOURCES}
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
i386/ashldi3.S
i386/ashrdi3.S
i386/divdi3.S
i386/floatdidf.S
i386/floatdisf.S
i386/floatundidf.S
i386/floatundisf.S
i386/lshrdi3.S
i386/moddi3.S
i386/muldi3.S
i386/udivdi3.S
i386/umoddi3.S
)
compiler-rt: add support for mingw-w64 in builtins The is so that we can avoid using libgcc and use compiler-rt with mingw-w64. Related driver patch http://reviews.llvm.org/D11077 I have tested this with mingw-w64 and everything seems to be in order. I also sent this patch to the mingw-w64 mailing list for them to look at. Patch by Martell Malone. Differential Revision: http://reviews.llvm.org/D11085 llvm-svn: 242539
2015-07-17 16:23:05 +00:00
[builtins] Omit 80-bit builtins on Android and MSVC long double is a 64-bit double-precision type on: - MSVC (32- and 64-bit x86) - Android (32-bit x86) long double is a 128-bit quad-precision type on x86_64 Android. The assembly variants of the 80-bit builtins are correct, but some of the builtins are implemented in C and require that long double be the 80-bit type passed via an x87 register. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D82153
2020-07-16 15:10:22 -07:00
if (NOT ANDROID)
set(i386_SOURCES
${i386_SOURCES}
${x86_80_BIT_SOURCES}
i386/floatdixf.S
i386/floatundixf.S
)
endif()
builtins: use C implementation on MSVC The assembly implementations use GNU syntax which MSVC doesn't handle. Rather than duplicate the code in a second syntax, use the C implementations. Patch by Tee Hao Wei! llvm-svn: 250360
2015-10-15 02:47:19 +00:00
if (WIN32)
set(i386_SOURCES
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
${i386_SOURCES}
[compiler-rt] Rename the now lone i386/chkstk2.S to i386/chkstk.S This step was omitted from the previous commit, 885d7b759b5c166c07c07f4c58c6e0ba110fb0c2, for clarity.
2023-08-30 00:05:06 +03:00
i386/chkstk.S
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
)
builtins: use C implementation on MSVC The assembly implementations use GNU syntax which MSVC doesn't handle. Rather than duplicate the code in a second syntax, use the C implementations. Patch by Tee Hao Wei! llvm-svn: 250360
2015-10-15 02:47:19 +00:00
endif()
else () # MSVC
# Use C versions of functions when building on MSVC
[CMake] Add partial support for MSVC in compiler-rt builtins, by Roman Shirokiy. This enables MSVC build of complex number arithmetic compiler-rt builtins. Differential Revision: http://reviews.llvm.org/D17452 llvm-svn: 261432
2016-02-20 12:56:04 +00:00
# MSVC's assembler takes Intel syntax, not AT&T syntax.
# Also use only MSVC compilable builtin implementations.
builtins: use C implementation on MSVC The assembly implementations use GNU syntax which MSVC doesn't handle. Rather than duplicate the code in a second syntax, use the C implementations. Patch by Tee Hao Wei! llvm-svn: 250360
2015-10-15 02:47:19 +00:00
set(x86_64_SOURCES
[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
${GENERIC_SOURCES}
${x86_ARCH_SOURCES}
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
x86_64/floatdidf.c
x86_64/floatdisf.c
)
[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
set(i386_SOURCES ${GENERIC_SOURCES} ${x86_ARCH_SOURCES})
builtins: use C implementation on MSVC The assembly implementations use GNU syntax which MSVC doesn't handle. Rather than duplicate the code in a second syntax, use the C implementations. Patch by Tee Hao Wei! llvm-svn: 250360
2015-10-15 02:47:19 +00:00
endif () # if (NOT MSVC)
[sanitizer] Add i686 arch to compiler-rt. This is needed so we can produce -i686- named libraries for x86 Android (which is i686-linux-android). An alternative solution would be keeping the "i386" name internally and tweaking the OUTPUT_NAME of compiler-rt libraries. llvm-svn: 218761
2014-10-01 12:55:06 +00:00
[compiler-rt] support armv4t The main thing that needed changing was excluding functionality that isn't supported on armv4t. So excluding Arm specific builtin assembly files. In the process some files were renamed and the source was annotated where appropriate, so it's a bit easier to follow what group of files are meant for what purpose. Reviewed By: peter.smith, nickdesaulniers Differential Revision: https://reviews.llvm.org/D138725
2022-12-01 20:52:18 +00:00
# builtin support for Targets that have Arm state or have Thumb2
set(arm_or_thumb2_base_SOURCES
Revert "Revert "[builtins] Rounding mode support for addxf3/subxf3"" Test failure fixed. This reverts commit e204d244badb2e9765a1020f41c773f63da208f4. llvm-svn: 371003
2019-09-05 01:05:05 +00:00
arm/fp_mode.c
builtins: split out the EABI and VFP ARM sources These are meant to only be included on certain targets. This only disables it for Windows ARM for now. Ideally these would be conditionally included as appropriate. llvm-svn: 277777
2016-08-04 21:58:39 +00:00
arm/bswapdi2.S
arm/bswapsi2.S
arm/clzdi2.S
arm/clzsi2.S
arm/comparesf2.S
arm/divmodsi4.S
arm/divsi3.S
arm/modsi3.S
[compiler-rt] support armv4t The main thing that needed changing was excluding functionality that isn't supported on armv4t. So excluding Arm specific builtin assembly files. In the process some files were renamed and the source was annotated where appropriate, so it's a bit easier to follow what group of files are meant for what purpose. Reviewed By: peter.smith, nickdesaulniers Differential Revision: https://reviews.llvm.org/D138725
2022-12-01 20:52:18 +00:00
arm/udivmodsi4.S
arm/udivsi3.S
arm/umodsi3.S
${GENERIC_SOURCES}
)
set(arm_sync_SOURCES
builtins: split out the EABI and VFP ARM sources These are meant to only be included on certain targets. This only disables it for Windows ARM for now. Ideally these would be conditionally included as appropriate. llvm-svn: 277777
2016-08-04 21:58:39 +00:00
arm/sync_fetch_and_add_4.S
arm/sync_fetch_and_add_8.S
arm/sync_fetch_and_and_4.S
arm/sync_fetch_and_and_8.S
arm/sync_fetch_and_max_4.S
arm/sync_fetch_and_max_8.S
arm/sync_fetch_and_min_4.S
arm/sync_fetch_and_min_8.S
arm/sync_fetch_and_nand_4.S
arm/sync_fetch_and_nand_8.S
arm/sync_fetch_and_or_4.S
arm/sync_fetch_and_or_8.S
arm/sync_fetch_and_sub_4.S
arm/sync_fetch_and_sub_8.S
arm/sync_fetch_and_umax_4.S
arm/sync_fetch_and_umax_8.S
arm/sync_fetch_and_umin_4.S
arm/sync_fetch_and_umin_8.S
arm/sync_fetch_and_xor_4.S
arm/sync_fetch_and_xor_8.S
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
)
builtins: split out the EABI and VFP ARM sources These are meant to only be included on certain targets. This only disables it for Windows ARM for now. Ideally these would be conditionally included as appropriate. llvm-svn: 277777
2016-08-04 21:58:39 +00:00
[compiler-rt] support armv4t The main thing that needed changing was excluding functionality that isn't supported on armv4t. So excluding Arm specific builtin assembly files. In the process some files were renamed and the source was annotated where appropriate, so it's a bit easier to follow what group of files are meant for what purpose. Reviewed By: peter.smith, nickdesaulniers Differential Revision: https://reviews.llvm.org/D138725
2022-12-01 20:52:18 +00:00
# builtin support for Thumb-only targets with very limited Thumb2 technology,
# such as v6-m and v8-m.baseline
set(thumb1_base_SOURCES
[Builtin] [ARM] Update CMake to support the build of armv6m Summary: Setting -DCOMPILER_RT_TEST_TARGET_TRIPLE=armv6m-none-eabi will enable the build of builtin functions ARMv6m. Currently, only those asms that support armv6m are added. TODO:All asm sin ARM_EABI_Sources are ported for thumb1 so Thumb1_EABI_Sources will be deprecated. Reviewers: rengolin, compnerd Reviewed By: compnerd Subscribers: aemerson, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D28463 llvm-svn: 292504
2017-01-19 18:46:11 +00:00
arm/divsi3.S
arm/udivsi3.S
arm/comparesf2.S
[Builtin][ARM] Implement addsf3/__aeabi_fadd for Thumb1 Summary: This patch implements addsf3/__aeabi_fadd in asm for Thumb1. Compared with generic C version (lib/fp_add_impl.inc), it 1. all constants are materialized instead of loading from constant pool 2. no stack spills (C version uses 136 bytes stack space) 3. clz() is called only when necessary. (C version always calls it) Reviewers: compnerd, rengolin, asl Reviewed By: asl Subscribers: efriedma, aemerson, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D29485 llvm-svn: 294172
2017-02-06 06:04:10 +00:00
arm/addsf3.S
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
${GENERIC_SOURCES}
)
[Builtin] [ARM] Update CMake to support the build of armv6m Summary: Setting -DCOMPILER_RT_TEST_TARGET_TRIPLE=armv6m-none-eabi will enable the build of builtin functions ARMv6m. Currently, only those asms that support armv6m are added. TODO:All asm sin ARM_EABI_Sources are ported for thumb1 so Thumb1_EABI_Sources will be deprecated. Reviewers: rengolin, compnerd Reviewed By: compnerd Subscribers: aemerson, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D28463 llvm-svn: 292504
2017-01-19 18:46:11 +00:00
builtins: split out the EABI and VFP ARM sources These are meant to only be included on certain targets. This only disables it for Windows ARM for now. Ideally these would be conditionally included as appropriate. llvm-svn: 277777
2016-08-04 21:58:39 +00:00
set(arm_EABI_SOURCES
Implement __aeabi_c{d,f}{cmpeq,cmple,rcmple}. Summary: Implement more missing ARM EABI runtime functions. Reviewers: rengolin, compnerd Subscribers: pirama, srhines, danalbert, aemerson, llvm-commits Differential Revision: http://reviews.llvm.org/D12089 llvm-svn: 245648
2015-08-21 00:25:37 +00:00
arm/aeabi_cdcmp.S
arm/aeabi_cdcmpeq_check_nan.c
arm/aeabi_cfcmp.S
arm/aeabi_cfcmpeq_check_nan.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
arm/aeabi_dcmp.S
builtins: add AEABI div0 functions Add the missing AEABI functions that are part of the base platform ABI specification. The provided implementation does the bare minimum to avoid requiring libc headers. This permits the use of compiler-rt on bare-metal environments which conform to EABI. llvm-svn: 217322
2014-09-06 21:34:02 +00:00
arm/aeabi_div0.c
Implement __aeabi_{f,d}rsub. Summary: Implement the missing ARM EABI functions _aeabi_frsub and __aeabi_drsub. Reviewers: rengolin, compnerd Subscribers: pirama, srhines, danalbert, aemerson, llvm-commits Differential Revision: http://reviews.llvm.org/D12088 llvm-svn: 245321
2015-08-18 18:10:33 +00:00
arm/aeabi_drsub.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
arm/aeabi_fcmp.S
Implement __aeabi_{f,d}rsub. Summary: Implement the missing ARM EABI functions _aeabi_frsub and __aeabi_drsub. Reviewers: rengolin, compnerd Subscribers: pirama, srhines, danalbert, aemerson, llvm-commits Differential Revision: http://reviews.llvm.org/D12088 llvm-svn: 245321
2015-08-18 18:10:33 +00:00
arm/aeabi_frsub.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
arm/aeabi_idivmod.S
arm/aeabi_ldivmod.S
arm/aeabi_memcmp.S
arm/aeabi_memcpy.S
arm/aeabi_memmove.S
arm/aeabi_memset.S
arm/aeabi_uidivmod.S
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
arm/aeabi_uldivmod.S
)
[Builtin] [ARM] Update CMake to support the build of armv6m Summary: Setting -DCOMPILER_RT_TEST_TARGET_TRIPLE=armv6m-none-eabi will enable the build of builtin functions ARMv6m. Currently, only those asms that support armv6m are added. TODO:All asm sin ARM_EABI_Sources are ported for thumb1 so Thumb1_EABI_Sources will be deprecated. Reviewers: rengolin, compnerd Reviewed By: compnerd Subscribers: aemerson, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D28463 llvm-svn: 292504
2017-01-19 18:46:11 +00:00
builtins: better categorisation of Thumb1 builtins Adjust the builtins to better annotate the Thumb1 routines and their purpose. Exclude the remaining thumb1 sources on Windows ARM. llvm-svn: 277828
2016-08-05 16:24:56 +00:00
set(arm_Thumb1_JT_SOURCES
arm/switch16.S
arm/switch32.S
arm/switch8.S
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
arm/switchu8.S
)
builtins: better categorisation of Thumb1 builtins Adjust the builtins to better annotate the Thumb1 routines and their purpose. Exclude the remaining thumb1 sources on Windows ARM. llvm-svn: 277828
2016-08-05 16:24:56 +00:00
set(arm_Thumb1_SjLj_EH_SOURCES
arm/restore_vfp_d8_d15_regs.S
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
arm/save_vfp_d8_d15_regs.S
)
[builtins] Add support for single-precision-only-FPU ARM targets. This patch enables building compiler-rt builtins for ARM targets that only support single-precision floating point instructions (e.g., those with -mfpu=fpv4-sp-d16). This fixes PR42838 Differential Revision: https://reviews.llvm.org/D90698
2020-11-12 14:44:54 +00:00
set(arm_Thumb1_VFPv2_DP_SOURCES
builtins: split out the EABI and VFP ARM sources These are meant to only be included on certain targets. This only disables it for Windows ARM for now. Ideally these would be conditionally included as appropriate. llvm-svn: 277777
2016-08-04 21:58:39 +00:00
arm/adddf3vfp.S
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
arm/divdf3vfp.S
arm/eqdf2vfp.S
arm/extendsfdf2vfp.S
arm/fixdfsivfp.S
arm/fixunsdfsivfp.S
arm/floatsidfvfp.S
arm/floatunssidfvfp.S
arm/gedf2vfp.S
arm/gtdf2vfp.S
arm/ledf2vfp.S
arm/ltdf2vfp.S
arm/muldf3vfp.S
arm/nedf2vfp.S
arm/negdf2vfp.S
arm/subdf3vfp.S
arm/truncdfsf2vfp.S
arm/unorddf2vfp.S
[builtins] Add support for single-precision-only-FPU ARM targets. This patch enables building compiler-rt builtins for ARM targets that only support single-precision floating point instructions (e.g., those with -mfpu=fpv4-sp-d16). This fixes PR42838 Differential Revision: https://reviews.llvm.org/D90698
2020-11-12 14:44:54 +00:00
)
set(arm_Thumb1_VFPv2_SP_SOURCES
arm/addsf3vfp.S
arm/divsf3vfp.S
arm/eqsf2vfp.S
arm/fixsfsivfp.S
arm/fixunssfsivfp.S
arm/floatsisfvfp.S
arm/floatunssisfvfp.S
arm/gesf2vfp.S
arm/gtsf2vfp.S
arm/lesf2vfp.S
arm/ltsf2vfp.S
arm/mulsf3vfp.S
arm/negsf2vfp.S
arm/nesf2vfp.S
arm/subsf3vfp.S
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
arm/unordsf2vfp.S
)
builtins: better categorisation of Thumb1 builtins Adjust the builtins to better annotate the Thumb1 routines and their purpose. Exclude the remaining thumb1 sources on Windows ARM. llvm-svn: 277828
2016-08-05 16:24:56 +00:00
set(arm_Thumb1_icache_SOURCES
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
arm/sync_synchronize.S
)
[compiler-rt] support armv4t The main thing that needed changing was excluding functionality that isn't supported on armv4t. So excluding Arm specific builtin assembly files. In the process some files were renamed and the source was annotated where appropriate, so it's a bit easier to follow what group of files are meant for what purpose. Reviewed By: peter.smith, nickdesaulniers Differential Revision: https://reviews.llvm.org/D138725
2022-12-01 20:52:18 +00:00
# thumb1 calling into Arm to cover support
Revert "[cmake] [ARM] Check if VFP is supported before including any VFP builtins" This reverts commit 2a10f5da5acb1b51d0a2ecf13dca0bf1de859db2. llvm-svn: 333232
2018-05-24 21:36:27 +00:00
set(arm_Thumb1_SOURCES
${arm_Thumb1_JT_SOURCES}
${arm_Thumb1_SjLj_EH_SOURCES}
[builtins] Add support for single-precision-only-FPU ARM targets. This patch enables building compiler-rt builtins for ARM targets that only support single-precision floating point instructions (e.g., those with -mfpu=fpv4-sp-d16). This fixes PR42838 Differential Revision: https://reviews.llvm.org/D90698
2020-11-12 14:44:54 +00:00
${arm_Thumb1_VFPv2_DP_SOURCES}
${arm_Thumb1_VFPv2_SP_SOURCES}
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
${arm_Thumb1_icache_SOURCES}
)
builtins: split out the EABI and VFP ARM sources These are meant to only be included on certain targets. This only disables it for Windows ARM for now. Ideally these would be conditionally included as appropriate. llvm-svn: 277777
2016-08-04 21:58:39 +00:00
[compiler-rt] support armv4t The main thing that needed changing was excluding functionality that isn't supported on armv4t. So excluding Arm specific builtin assembly files. In the process some files were renamed and the source was annotated where appropriate, so it's a bit easier to follow what group of files are meant for what purpose. Reviewed By: peter.smith, nickdesaulniers Differential Revision: https://reviews.llvm.org/D138725
2022-12-01 20:52:18 +00:00
# base functionality for Arm Targets prior to Arm v7-a and Armv6-m such as v6,
# v5t, v4t
set(arm_min_SOURCES
${arm_or_thumb2_base_SOURCES}
${arm_EABI_SOURCES}
)
builtins: Allow building windows arm functions for mingw When building with clang/LLVM in MSVC mode, the msvcrt libraries contain these functions. When building in a mingw environment, we need to provide them somehow, e.g. via compiler-rt. The aeabi divmod functions work in the same way as the corresponding __rt_*div* functions for windows, but their parameters are swapped. The functions for converting float to integer and vice versa are the same as their aeabi equivalents, only with different function names. Differential Revision: https://reviews.llvm.org/D26183 llvm-svn: 287465
2016-11-19 21:22:38 +00:00
if(MINGW)
set(arm_SOURCES
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
arm/aeabi_idivmod.S
arm/aeabi_ldivmod.S
arm/aeabi_uidivmod.S
arm/aeabi_uldivmod.S
arm/chkstk.S
[compiler-rt] support armv4t The main thing that needed changing was excluding functionality that isn't supported on armv4t. So excluding Arm specific builtin assembly files. In the process some files were renamed and the source was annotated where appropriate, so it's a bit easier to follow what group of files are meant for what purpose. Reviewed By: peter.smith, nickdesaulniers Differential Revision: https://reviews.llvm.org/D138725
2022-12-01 20:52:18 +00:00
${arm_or_thumb2_base_SOURCES}
${arm_sync_SOURCES}
)
set(thumb1_SOURCES
${thumb1_base_SOURCES}
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
)
build: fix building for Windows after SVN r287465 The previous change for enabling MinGW did not preserve the Win32 check and added the EABI specific routines to a Windows build which does not use the EABI routines. Correct the conditional check for that. llvm-svn: 288422
2016-12-01 22:00:54 +00:00
elseif(NOT WIN32)
builtins: better categorisation of Thumb1 builtins Adjust the builtins to better annotate the Thumb1 routines and their purpose. Exclude the remaining thumb1 sources on Windows ARM. llvm-svn: 277828
2016-08-05 16:24:56 +00:00
# TODO the EABI sources should only be added to EABI targets
builtins: split out the EABI and VFP ARM sources These are meant to only be included on certain targets. This only disables it for Windows ARM for now. Ideally these would be conditionally included as appropriate. llvm-svn: 277777
2016-08-04 21:58:39 +00:00
set(arm_SOURCES
[compiler-rt] support armv4t The main thing that needed changing was excluding functionality that isn't supported on armv4t. So excluding Arm specific builtin assembly files. In the process some files were renamed and the source was annotated where appropriate, so it's a bit easier to follow what group of files are meant for what purpose. Reviewed By: peter.smith, nickdesaulniers Differential Revision: https://reviews.llvm.org/D138725
2022-12-01 20:52:18 +00:00
${arm_or_thumb2_base_SOURCES}
${arm_sync_SOURCES}
builtins: split out the EABI and VFP ARM sources These are meant to only be included on certain targets. This only disables it for Windows ARM for now. Ideally these would be conditionally included as appropriate. llvm-svn: 277777
2016-08-04 21:58:39 +00:00
${arm_EABI_SOURCES}
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
${arm_Thumb1_SOURCES}
)
[Builtin] [ARM] Update CMake to support the build of armv6m Summary: Setting -DCOMPILER_RT_TEST_TARGET_TRIPLE=armv6m-none-eabi will enable the build of builtin functions ARMv6m. Currently, only those asms that support armv6m are added. TODO:All asm sin ARM_EABI_Sources are ported for thumb1 so Thumb1_EABI_Sources will be deprecated. Reviewers: rengolin, compnerd Reviewed By: compnerd Subscribers: aemerson, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D28463 llvm-svn: 292504
2017-01-19 18:46:11 +00:00
set(thumb1_SOURCES
[compiler-rt] support armv4t The main thing that needed changing was excluding functionality that isn't supported on armv4t. So excluding Arm specific builtin assembly files. In the process some files were renamed and the source was annotated where appropriate, so it's a bit easier to follow what group of files are meant for what purpose. Reviewed By: peter.smith, nickdesaulniers Differential Revision: https://reviews.llvm.org/D138725
2022-12-01 20:52:18 +00:00
${thumb1_base_SOURCES}
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
${arm_EABI_SOURCES}
)
builtins: split out the EABI and VFP ARM sources These are meant to only be included on certain targets. This only disables it for Windows ARM for now. Ideally these would be conditionally included as appropriate. llvm-svn: 277777
2016-08-04 21:58:39 +00:00
endif()
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 09:20:33 +00:00
[compiler-rt] Add AArch64 to CMake configuration and several missing builtins Summary: Currently CMake doesn't build builtins for AArch64 and if one does this anyway it's likely that at least `__multc3`, `__floatditf` and `__floatunditf` will be missing. There is actually more builtins to add, but these come from different libc implementations, thus providing them makes compiler-rt for AArch64 good enough at least for basic usage. Builtins implementation were originally taken from FreeBSD project: * [[ https://reviews.freebsd.org/D2173 | __multc3 ]] * [[ https://reviews.freebsd.org/D2174 | __floatditf and __floatunditf ]] Until they have been tested to find mistakes in `__float*` functions. `__floatditf` was based on `__floatsitf`, which had the same mistakes (fixed it in r243746). Version of the builtins in this patch are fixed and complemented with basic tests. Additionally they were tested via GCC's torture (this is what revealed these issues). P.S. Ed (author of FreeBSD patches) asked for feedback on the list some time ago (here [[ http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/084064.html | here ]]) and got no response, but it seems to be worth adding these builtins as is and extracting common part later. Reviewers: howard.hinnant, t.p.northover, jmolloy, enefaim, rengolin, zatrazz Subscribers: asl, emaste, samsonov, aemerson, llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D11679 llvm-svn: 245296
2015-08-18 13:43:37 +00:00
set(aarch64_SOURCES
[compiler-rt][mips] Add support for quad precision builtins for mips64 Match the builtins that GCC provides for IEEE754 quad precision on MIPS64. Also, enable building them with clang as PR20098 is resolved. Disable tests for xf and xc modes as MIPS doesn't support that mode in hardware or software. Reviewers: slthakur Differential Revision: https://reviews.llvm.org/D32794 llvm-svn: 302147
2017-05-04 13:34:17 +00:00
${GENERIC_TF_SOURCES}
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
${GENERIC_SOURCES}
[builtins] Refactor cpu_model support to reduce #if nesting. NFCI Reviewers: petrhosek, DavidSpickett Pull Request: https://github.com/llvm/llvm-project/pull/75635
2023-12-19 11:09:50 -07:00
cpu_model/aarch64.c
Revert "Revert "[builtins] Rounding mode support for addxf3/subxf3"" Test failure fixed. This reverts commit e204d244badb2e9765a1020f41c773f63da208f4. llvm-svn: 371003
2019-09-05 01:05:05 +00:00
aarch64/fp_mode.c
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
)
[compiler-rt] Add AArch64 to CMake configuration and several missing builtins Summary: Currently CMake doesn't build builtins for AArch64 and if one does this anyway it's likely that at least `__multc3`, `__floatditf` and `__floatunditf` will be missing. There is actually more builtins to add, but these come from different libc implementations, thus providing them makes compiler-rt for AArch64 good enough at least for basic usage. Builtins implementation were originally taken from FreeBSD project: * [[ https://reviews.freebsd.org/D2173 | __multc3 ]] * [[ https://reviews.freebsd.org/D2174 | __floatditf and __floatunditf ]] Until they have been tested to find mistakes in `__float*` functions. `__floatditf` was based on `__floatsitf`, which had the same mistakes (fixed it in r243746). Version of the builtins in this patch are fixed and complemented with basic tests. Additionally they were tested via GCC's torture (this is what revealed these issues). P.S. Ed (author of FreeBSD patches) asked for feedback on the list some time ago (here [[ http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/084064.html | here ]]) and got no response, but it seems to be worth adding these builtins as is and extracting common part later. Reviewers: howard.hinnant, t.p.northover, jmolloy, enefaim, rengolin, zatrazz Subscribers: asl, emaste, samsonov, aemerson, llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D11679 llvm-svn: 245296
2015-08-18 13:43:37 +00:00
[compiler-rt] Don't build SME routines if __arm_cpu_features is not initialised. (#119703) According to the conversation [here](https://github.com/llvm/llvm-project/pull/119414#issuecomment-2536495859), some platforms don't enable `__arm_cpu_features` with a global constructor, but rather do so lazily when called from the FMV resolver. PR #119414 removed the CMake guard to check to see if the targetted platform is baremetal or supports sys/auxv. Without this check, the routines rely on `__arm_cpu_features` being initialised when they may not be, depending on the platform. This PR simply avoids building the SME routines for those platforms for now.
2024-12-12 15:59:48 +00:00
set(COMPILER_RT_AARCH64_FMV_USES_GLOBAL_CONSTRUCTOR NOT(FUCHSIA OR APPLE))
[AArch64][compiler-rt] Disable SME ABI routines if function multiversioning is not supported (#94973) This prevents build failures when building with `DISABLE_AARCH64_FMV`, see https://github.com/llvm/llvm-project/pull/92921.
2024-06-12 09:35:57 +01:00
if (COMPILER_RT_HAS_AARCH64_SME)
[AArch64][SME] Add Darwin specific SME ABI routines. Our platform has some constraints that allow us to make assumptions that aren't generally applicable to other platforms. We keep an entirely separate .s file for the routines.
2025-01-03 22:07:27 -08:00
if (APPLE)
list(APPEND aarch64_SOURCES aarch64/arm_apple_sme_abi.s)
set_source_files_properties(aarch64/arm_apple_sme_abi.s PROPERTIES COMPILE_FLAGS -march=armv8a+sme)
message(STATUS "AArch64 Apple SME ABI routines enabled")
elseif (NOT COMPILER_RT_DISABLE_AARCH64_FMV AND COMPILER_RT_HAS_FNO_BUILTIN_FLAG AND COMPILER_RT_AARCH64_FMV_USES_GLOBAL_CONSTRUCTOR)
[compiler-rt][AArch64] Rewrite SME routines to all use __aarch64_cpu_features. (#119414) When #92921 added the `__arm_get_current_vg` functionality, it used the FMV feature bits mechanism rather than the mechanism that was previously added for SME which called `getauxval` on Linux platforms or `__aarch64_sme_accessible` required for baremetal libraries. It is better to always use `__aarch64_cpu_features`. For baremetal we still need to rely on `__arm_sme_accessible` to initialise the struct.
2024-12-11 15:53:17 +00:00
list(APPEND aarch64_SOURCES aarch64/sme-abi.S aarch64/sme-libc-mem-routines.S aarch64/sme-abi-assert.c aarch64/sme-libc-routines.c)
[AArch64][compiler-rt] Disable SME ABI routines if function multiversioning is not supported (#94973) This prevents build failures when building with `DISABLE_AARCH64_FMV`, see https://github.com/llvm/llvm-project/pull/92921.
2024-06-12 09:35:57 +01:00
message(STATUS "AArch64 SME ABI routines enabled")
set_source_files_properties(aarch64/sme-libc-routines.c PROPERTIES COMPILE_FLAGS "-fno-builtin")
else()
if(COMPILER_RT_DISABLE_AARCH64_FMV)
message(WARNING "AArch64 SME ABI routines require function multiversioning support.")
endif()
if(NOT COMPILER_RT_HAS_FNO_BUILTIN_FLAG)
message(WARNING "AArch64 SME ABI routines require '-fno-builtin'")
endif()
if(NOT (COMPILER_RT_HAS_AUXV OR COMPILER_RT_BAREMETAL_BUILD))
message(WARNING "AArch64 SME ABI routines requires sys/auxv.h or COMPILER_RT_BAREMETAL_BUILD flag")
endif()
message(STATUS "AArch64 SME ABI routines disabled")
endif()
[AArch64][compiler-rt] Only build SME ABI routines when compiler supports asm. (#68991) This also adds the .variant_pcs directive to some functions from which it was previously missing.
2023-10-14 16:35:03 +01:00
endif()
[AArch64] Compiler-rt interface for out-of-line atomics. Out-of-line helper functions to support LSE deployment added. This is a port of libgcc implementation: https://gcc.gnu.org/git/?p=gcc.git;h=33befddcb849235353dc263db1c7d07dc15c9faa Differential Revision: https://reviews.llvm.org/D91156
2020-11-20 15:02:57 +00:00
# Generate outline atomics helpers from lse.S base
[compiler-rt][AArch64] Put outline atomic helpers into dedicated dir. Differential Revision: https://reviews.llvm.org/D92724
2020-12-05 20:45:22 +00:00
set(OA_HELPERS_DIR "${CMAKE_CURRENT_BINARY_DIR}/outline_atomic_helpers.dir")
Re-apply "[CMake][compiler-rt][AArch64] Avoid preprocessing LSE builtins separately" aa772fc85e0f526615c78b9c3979c2be945a754c (D92530) has landed fixing relocations on Darwin. 3000c19df64f89ff319590f3a6e4d6b93d20983d (D93236) has landed working around an assembly parser bug on Darwin. Previous quick-fix d9697c2e6b153ac7dc40a69450d9b672f71b1029 (D93198) included in this commit. Invoking the preprocessor ourselves is fragile and would require us to replicate CMake's handling of definitions, compiler flags, etc for proper compatibility. In my toolchain builds this notably resulted in a bunch of warnings from unused flags as my CMAKE_C_FLAGS includes CPU-specific optimization options. Notably this part was already duplicating the logic for VISIBILITY_HIDDEN define. Instead, symlink the files and set the proper set of defines on each. This should also be faster as we avoid invoking the compiler multiple times. Fixes https://llvm.org/PR48494 Differential Revision: https://reviews.llvm.org/D93278
2020-12-15 08:15:58 +02:00
file(MAKE_DIRECTORY "${OA_HELPERS_DIR}")
[AArch64] Compiler-rt interface for out-of-line atomics. Out-of-line helper functions to support LSE deployment added. This is a port of libgcc implementation: https://gcc.gnu.org/git/?p=gcc.git;h=33befddcb849235353dc263db1c7d07dc15c9faa Differential Revision: https://reviews.llvm.org/D91156
2020-11-20 15:02:57 +00:00
[CMake][compiler-rt] Use copying instead of symlinking for LSE builtins on non-Unix-likes As reported in D93278 post-review symlinking requires privilege escalation on Windows. Copying is functionally same, so fallback to it for systems that aren't Unix-like. This is similar to the solution in AddLLVM.cmake. Reviewed By: ikudrin Differential Revision: https://reviews.llvm.org/D98111
2021-03-06 11:45:57 +02:00
if(CMAKE_HOST_UNIX)
set(COMPILER_RT_LINK_OR_COPY create_symlink)
else()
set(COMPILER_RT_LINK_OR_COPY copy)
endif()
[AArch64] Compiler-rt interface for out-of-line atomics. Out-of-line helper functions to support LSE deployment added. This is a port of libgcc implementation: https://gcc.gnu.org/git/?p=gcc.git;h=33befddcb849235353dc263db1c7d07dc15c9faa Differential Revision: https://reviews.llvm.org/D91156
2020-11-20 15:02:57 +00:00
foreach(pat cas swp ldadd ldclr ldeor ldset)
foreach(size 1 2 4 8 16)
[builtins][AArch64] Implement _sync out-of-line atomics Whilst Clang does not use these, recent GCC does, and so on systems such as FreeBSD that wish to use compiler-rt as the system runtime library but also wish to support building programs with GCC these interfaces are needed. This is a light adaptation of the code committed to GCC by Sebastian Pop <spop@amazon.com>, relicensed with permission for use in compiler-rt. Fixes https://github.com/llvm/llvm-project/issues/63483 Reviewed By: sebpop, MaskRay Differential Revision: https://reviews.llvm.org/D158536
2023-09-04 01:46:00 +01:00
foreach(model 1 2 3 4 5)
[AArch64] Compiler-rt interface for out-of-line atomics. Out-of-line helper functions to support LSE deployment added. This is a port of libgcc implementation: https://gcc.gnu.org/git/?p=gcc.git;h=33befddcb849235353dc263db1c7d07dc15c9faa Differential Revision: https://reviews.llvm.org/D91156
2020-11-20 15:02:57 +00:00
if(pat STREQUAL "cas" OR NOT size STREQUAL "16")
[builtins][CMake] Replace custom target for lse_builtin symlinks (#66936) Using custom target with BYPRODUCTS results in symlinks being recreated on every build (the build is always dirty). We could instead use custom commands to generate the symlinks and by adding the output to the list of sources, build system will ensure those are created as needed.
2023-09-21 11:57:18 -07:00
set(source_asm "${CMAKE_CURRENT_SOURCE_DIR}/aarch64/lse.S")
Re-apply "[CMake][compiler-rt][AArch64] Avoid preprocessing LSE builtins separately" aa772fc85e0f526615c78b9c3979c2be945a754c (D92530) has landed fixing relocations on Darwin. 3000c19df64f89ff319590f3a6e4d6b93d20983d (D93236) has landed working around an assembly parser bug on Darwin. Previous quick-fix d9697c2e6b153ac7dc40a69450d9b672f71b1029 (D93198) included in this commit. Invoking the preprocessor ourselves is fragile and would require us to replicate CMake's handling of definitions, compiler flags, etc for proper compatibility. In my toolchain builds this notably resulted in a bunch of warnings from unused flags as my CMAKE_C_FLAGS includes CPU-specific optimization options. Notably this part was already duplicating the logic for VISIBILITY_HIDDEN define. Instead, symlink the files and set the proper set of defines on each. This should also be faster as we avoid invoking the compiler multiple times. Fixes https://llvm.org/PR48494 Differential Revision: https://reviews.llvm.org/D93278
2020-12-15 08:15:58 +02:00
set(helper_asm "${OA_HELPERS_DIR}/outline_atomic_${pat}${size}_${model}.S")
[builtins][CMake] Replace custom target for lse_builtin symlinks (#66936) Using custom target with BYPRODUCTS results in symlinks being recreated on every build (the build is always dirty). We could instead use custom commands to generate the symlinks and by adding the output to the list of sources, build system will ensure those are created as needed.
2023-09-21 11:57:18 -07:00
add_custom_command(
OUTPUT "${helper_asm}"
COMMAND ${CMAKE_COMMAND} -E ${COMPILER_RT_LINK_OR_COPY} "${source_asm}" "${helper_asm}"
DEPENDS "${source_asm}"
)
Re-apply "[CMake][compiler-rt][AArch64] Avoid preprocessing LSE builtins separately" aa772fc85e0f526615c78b9c3979c2be945a754c (D92530) has landed fixing relocations on Darwin. 3000c19df64f89ff319590f3a6e4d6b93d20983d (D93236) has landed working around an assembly parser bug on Darwin. Previous quick-fix d9697c2e6b153ac7dc40a69450d9b672f71b1029 (D93198) included in this commit. Invoking the preprocessor ourselves is fragile and would require us to replicate CMake's handling of definitions, compiler flags, etc for proper compatibility. In my toolchain builds this notably resulted in a bunch of warnings from unused flags as my CMAKE_C_FLAGS includes CPU-specific optimization options. Notably this part was already duplicating the logic for VISIBILITY_HIDDEN define. Instead, symlink the files and set the proper set of defines on each. This should also be faster as we avoid invoking the compiler multiple times. Fixes https://llvm.org/PR48494 Differential Revision: https://reviews.llvm.org/D93278
2020-12-15 08:15:58 +02:00
set_source_files_properties("${helper_asm}"
PROPERTIES
COMPILE_DEFINITIONS "L_${pat};SIZE=${size};MODEL=${model}"
INCLUDE_DIRECTORIES "${CMAKE_CURRENT_SOURCE_DIR}"
[AArch64] Compiler-rt interface for out-of-line atomics. Out-of-line helper functions to support LSE deployment added. This is a port of libgcc implementation: https://gcc.gnu.org/git/?p=gcc.git;h=33befddcb849235353dc263db1c7d07dc15c9faa Differential Revision: https://reviews.llvm.org/D91156
2020-11-20 15:02:57 +00:00
)
Re-apply "[CMake][compiler-rt][AArch64] Avoid preprocessing LSE builtins separately" aa772fc85e0f526615c78b9c3979c2be945a754c (D92530) has landed fixing relocations on Darwin. 3000c19df64f89ff319590f3a6e4d6b93d20983d (D93236) has landed working around an assembly parser bug on Darwin. Previous quick-fix d9697c2e6b153ac7dc40a69450d9b672f71b1029 (D93198) included in this commit. Invoking the preprocessor ourselves is fragile and would require us to replicate CMake's handling of definitions, compiler flags, etc for proper compatibility. In my toolchain builds this notably resulted in a bunch of warnings from unused flags as my CMAKE_C_FLAGS includes CPU-specific optimization options. Notably this part was already duplicating the logic for VISIBILITY_HIDDEN define. Instead, symlink the files and set the proper set of defines on each. This should also be faster as we avoid invoking the compiler multiple times. Fixes https://llvm.org/PR48494 Differential Revision: https://reviews.llvm.org/D93278
2020-12-15 08:15:58 +02:00
list(APPEND aarch64_SOURCES "${helper_asm}")
[AArch64] Compiler-rt interface for out-of-line atomics. Out-of-line helper functions to support LSE deployment added. This is a port of libgcc implementation: https://gcc.gnu.org/git/?p=gcc.git;h=33befddcb849235353dc263db1c7d07dc15c9faa Differential Revision: https://reviews.llvm.org/D91156
2020-11-20 15:02:57 +00:00
endif()
endforeach(model)
endforeach(size)
endforeach(pat)
[builtins] Implement __chkstk for arm64 windows Differential Revision: https://reviews.llvm.org/D41134 llvm-svn: 321151
2017-12-20 06:52:52 +00:00
if (MINGW)
set(aarch64_SOURCES
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
${aarch64_SOURCES}
aarch64/chkstk.S
)
[builtins] Implement __chkstk for arm64 windows Differential Revision: https://reviews.llvm.org/D41134 llvm-svn: 321151
2017-12-20 06:52:52 +00:00
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
set(amdgcn_SOURCES ${GENERIC_SOURCES})
[compiler-rt] support armv4t The main thing that needed changing was excluding functionality that isn't supported on armv4t. So excluding Arm specific builtin assembly files. In the process some files were renamed and the source was annotated where appropriate, so it's a bit easier to follow what group of files are meant for what purpose. Reviewed By: peter.smith, nickdesaulniers Differential Revision: https://reviews.llvm.org/D138725
2022-12-01 20:52:18 +00:00
set(armv4t_SOURCES ${arm_min_SOURCES})
[compiler-rt] support armv5t, armv6 The legwork for these was done by https://reviews.llvm.org/D138725. Here we're just adding the arch names to the cmake files and linking them to arm_min_SOURCES. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D141322
2023-01-11 10:00:02 +00:00
set(armv5te_SOURCES ${arm_min_SOURCES})
set(armv6_SOURCES ${arm_min_SOURCES})
build: create two versions of ARM builtins This adds a new name for ARM32 (armhf). We now force that the default build for ARM32 (arm) to be soft-float ABI. This has a corresponding clang change to look for these names based on the floating point ABI. The functions are built identically (the functions are marked as AAPCS, so the calling convention does not change, as per the RTABI specification), however, the object file contains attributes indicating the build configuration which the linker will ensure are not mix and matched. We now built the appropriate named archive so that we can link properly. llvm-svn: 248648
2015-09-26 03:26:01 +00:00
set(armhf_SOURCES ${arm_SOURCES})
[CMake] Fix building builtins on Linux and Darwin. Summary: I broke building the builtins with r245967. This fixes them on Linux and builds them properly for Darwin. The old code could not be made to work on Darwin as a result of the refactoring of add_compiler_rt_runtime, so I had to rework the way they are built for Darwin. This solution is not ideal and will be fixed in subsequent commits. I just want to get this in so everything is working again. Reviewers: samsonov, chh, compnerd, bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12500 llvm-svn: 246487
2015-08-31 21:24:50 +00:00
set(armv7_SOURCES ${arm_SOURCES})
set(armv7s_SOURCES ${arm_SOURCES})
[asan] Add iOS support. llvm-svn: 259451
2016-02-02 02:01:17 +00:00
set(armv7k_SOURCES ${arm_SOURCES})
[CMake] Fix building builtins on Linux and Darwin. Summary: I broke building the builtins with r245967. This fixes them on Linux and builds them properly for Darwin. The old code could not be made to work on Darwin as a result of the refactoring of add_compiler_rt_runtime, so I had to rework the way they are built for Darwin. This solution is not ideal and will be fixed in subsequent commits. I just want to get this in so everything is working again. Reviewers: samsonov, chh, compnerd, bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12500 llvm-svn: 246487
2015-08-31 21:24:50 +00:00
set(arm64_SOURCES ${aarch64_SOURCES})
[builtins] Build for arm64e for Darwin https://github.com/apple/swift/pull/30112/ makes the Swift standard library for iOS build for arm64e. If you're building Swift against your own LLVM, this in turn requires having the builtins built for arm64e, otherwise you won't be able to use the builtins (which will in turn lead to an undefined symbol for `__isOSVersionAtLeast`). Make the builtins build for arm64e to fix this. Differential Revision: https://reviews.llvm.org/D76041
2020-03-11 19:58:15 -07:00
set(arm64e_SOURCES ${aarch64_SOURCES})
[builtins] Build for arm64_32 for watchOS (Darwin) Trying to build the builtins code fails because `arm64_32_SOURCES` is missing. Setting it to the same list used for `aarch64_SOURCES` solves that problem and allow the builtins to compile for that architecture. Additionally, arm64_32 is added as a possible architecture for watchos platforms. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D99690
2021-04-01 17:15:56 -07:00
set(arm64_32_SOURCES ${aarch64_SOURCES})
[CMake] Fix building builtins on Linux and Darwin. Summary: I broke building the builtins with r245967. This fixes them on Linux and builds them properly for Darwin. The old code could not be made to work on Darwin as a result of the refactoring of add_compiler_rt_runtime, so I had to rework the way they are built for Darwin. This solution is not ideal and will be fixed in subsequent commits. I just want to get this in so everything is working again. Reviewers: samsonov, chh, compnerd, bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12500 llvm-svn: 246487
2015-08-31 21:24:50 +00:00
[CMake] [Darwin] Support building the macho_embedded builtin libraries. Summary: This ports functionality from the clang_macho_embedded.mk platform makefile over to CMake. Reviewers: bogner, samsonov, bob.wilson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13226 llvm-svn: 248850
2015-09-29 23:13:45 +00:00
# macho_embedded archs
[Builtin] [ARM] Update CMake to support the build of armv6m Summary: Setting -DCOMPILER_RT_TEST_TARGET_TRIPLE=armv6m-none-eabi will enable the build of builtin functions ARMv6m. Currently, only those asms that support armv6m are added. TODO:All asm sin ARM_EABI_Sources are ported for thumb1 so Thumb1_EABI_Sources will be deprecated. Reviewers: rengolin, compnerd Reviewed By: compnerd Subscribers: aemerson, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D28463 llvm-svn: 292504
2017-01-19 18:46:11 +00:00
set(armv6m_SOURCES ${thumb1_SOURCES})
[CMake] [Darwin] Support building the macho_embedded builtin libraries. Summary: This ports functionality from the clang_macho_embedded.mk platform makefile over to CMake. Reviewers: bogner, samsonov, bob.wilson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13226 llvm-svn: 248850
2015-09-29 23:13:45 +00:00
set(armv7m_SOURCES ${arm_SOURCES})
set(armv7em_SOURCES ${arm_SOURCES})
[compiler-rt][builtins] Support builtins for armv8m.base This allows building the compiler builtins library for the Armv8-M Baseline architecture. It can be built in the same way as other baremetal targets using the appropriate '--target' flag (e.g. --target=armv8m.base-eabi). NOTE: As with the other Cortex-M targets, only the builtins library is supported. There is no support for sanitizers, etc. The armv8m.base architecture is a superset of armv6m, so adding it to the cmake files using thumb1_SOURCES is almost enough for it to compile. Minor changes are needed to divsi3 and udivsi3, because armv8m.base does have support for div instructions but not mov with an immediate operand. Reviewed By: MaskRay, peter.smith Differential Revision: https://reviews.llvm.org/D143297
2023-03-14 17:20:54 -07:00
set(armv8m.base_SOURCES ${thumb1_SOURCES})
[arm][compiler-rt] add armv8m.main and arv8.1m.main targets These changes were enough to compile compiler-rt builtins for armv8m.main and armv8.1m.main. Differential Revision: https://reviews.llvm.org/D99600
2021-03-30 16:57:50 +01:00
set(armv8m.main_SOURCES ${arm_SOURCES})
set(armv8.1m.main_SOURCES ${arm_SOURCES})
[CMake] [Darwin] Support building the macho_embedded builtin libraries. Summary: This ports functionality from the clang_macho_embedded.mk platform makefile over to CMake. Reviewers: bogner, samsonov, bob.wilson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13226 llvm-svn: 248850
2015-09-29 23:13:45 +00:00
[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
# 8-bit AVR MCU
set(avr_SOURCES
avr/mulqi3.S
avr/mulhi3.S
avr/exit.S
[compiler-rt][builtins] Add helper functions for uint16/sint16/uint8/sint8 div and mod __udivmodhi4 : uint16 div and mod __udivmodqi4 : uint8 div and mod __divmodhi4 : sint16 div and mod __divmodqi4 : sint8 div and mod The above helper functions in libgcc have special ABI as described at https://gcc.gnu.org/wiki/avr-gcc#Exceptions_to_the_Calling_Convention . Reviewed By: aykevl Differential Revision: https://reviews.llvm.org/D124600
2022-05-05 07:35:09 +00:00
avr/divmodhi4.S
avr/udivmodhi4.S
avr/divmodqi4.S
avr/udivmodqi4.S
[compiler-rt][AVR] Fix avr_SOURCES CMake variable D123200 did not include the generic sources, which means that only the AVR-specific sources were compiled. With this change, generic sources are included as expected. Tested with the following commands: cmake -G Ninja -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE=avr -DCOMPILER_RT_BAREMETAL_BUILD=1 -DCMAKE_C_COMPILER=clang-14 -DCMAKE_C_FLAGS="--target=avr -mmcu=avr5 -nostdlibinc -mdouble=64" ../path/to/builtins ninja Differential Revision: https://reviews.llvm.org/D124969
2022-05-05 00:46:27 +02:00
${GENERIC_SOURCES}
[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
)
Add basic compiler-rt builtins support for hexagon. Differential Revision: https://reviews.llvm.org/D46364 llvm-svn: 331881
2018-05-09 14:44:54 +00:00
# hexagon arch
set(hexagon_SOURCES
hexagon/common_entry_exit_abi1.S
hexagon/common_entry_exit_abi2.S
hexagon/common_entry_exit_legacy.S
hexagon/dfaddsub.S
hexagon/dfdiv.S
hexagon/dffma.S
hexagon/dfminmax.S
hexagon/dfmul.S
hexagon/dfsqrt.S
hexagon/divdi3.S
hexagon/divsi3.S
hexagon/fastmath2_dlib_asm.S
hexagon/fastmath2_ldlib_asm.S
hexagon/fastmath_dlib_asm.S
hexagon/memcpy_forward_vp4cp4n2.S
hexagon/memcpy_likely_aligned.S
hexagon/moddi3.S
hexagon/modsi3.S
hexagon/sfdiv_opt.S
hexagon/sfsqrt_opt.S
hexagon/udivdi3.S
hexagon/udivmoddi4.S
hexagon/udivmodsi4.S
hexagon/udivsi3.S
hexagon/umoddi3.S
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
hexagon/umodsi3.S
[Hexagon] Define __ELF__ by default. Differential Revision: https://reviews.llvm.org/D74972
2020-02-21 13:41:22 -06:00
${GENERIC_SOURCES}
${GENERIC_TF_SOURCES}
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
)
Add basic compiler-rt builtins support for hexagon. Differential Revision: https://reviews.llvm.org/D46364 llvm-svn: 331881
2018-05-09 14:44:54 +00:00
[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
set(loongarch_SOURCES
loongarch/fp_mode.c
${GENERIC_SOURCES}
${GENERIC_TF_SOURCES}
)
set(loongarch64_SOURCES
${loongarch_SOURCES}
)
Add basic compiler-rt builtins support for hexagon. Differential Revision: https://reviews.llvm.org/D46364 llvm-svn: 331881
2018-05-09 14:44:54 +00:00
[builtins] Enable building of the builtins library for MIPS targets. Reviewers: howard.hinnant, samsonov Subscribers: samsonov, dsanders, llvm-commits Differential Revision: http://reviews.llvm.org/D13098 llvm-svn: 249382
2015-10-06 09:02:38 +00:00
set(mips_SOURCES ${GENERIC_SOURCES})
set(mipsel_SOURCES ${mips_SOURCES})
[compiler-rt][mips] Add support for quad precision builtins for mips64 Match the builtins that GCC provides for IEEE754 quad precision on MIPS64. Also, enable building them with clang as PR20098 is resolved. Disable tests for xf and xc modes as MIPS doesn't support that mode in hardware or software. Reviewers: slthakur Differential Revision: https://reviews.llvm.org/D32794 llvm-svn: 302147
2017-05-04 13:34:17 +00:00
set(mips64_SOURCES ${GENERIC_TF_SOURCES}
${mips_SOURCES})
set(mips64el_SOURCES ${GENERIC_TF_SOURCES}
${mips_SOURCES})
[builtins] Enable building of the builtins library for MIPS targets. Reviewers: howard.hinnant, samsonov Subscribers: samsonov, dsanders, llvm-commits Differential Revision: http://reviews.llvm.org/D13098 llvm-svn: 249382
2015-10-06 09:02:38 +00:00
[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
set(nvptx64_SOURCES ${GENERIC_SOURCES})
Revert "[compiler-rt][CMake] Enable TF intrinsics on powerpc32 Linux" As mentioned in https://reviews.llvm.org/D121379#3690593, this change broke the build of compiler-rt targeting powerpc using GCC. The 32-bit powerpc target is not supposed to emit 128-bit libcalls -- if it does, then that's a backend bug and needs to be fixed there. This reverts commit 8f24a56a3a9363f353c8da318d97491a6818781d. Differential Revision: https://reviews.llvm.org/D130988
2022-08-02 15:34:42 +02:00
set(powerpc_SOURCES ${GENERIC_SOURCES})
[compiler-rt][CMake] Support powerpcspe build Reviewed By: jhibbits, MaskRay Differential Revision: https://reviews.llvm.org/D98836
2021-11-26 13:29:06 -08:00
set(powerpcspe_SOURCES ${GENERIC_SOURCES})
Revert "[compiler-rt][CMake] Enable TF intrinsics on powerpc32 Linux" As mentioned in https://reviews.llvm.org/D121379#3690593, this change broke the build of compiler-rt targeting powerpc using GCC. The 32-bit powerpc target is not supposed to emit 128-bit libcalls -- if it does, then that's a backend bug and needs to be fixed there. This reverts commit 8f24a56a3a9363f353c8da318d97491a6818781d. Differential Revision: https://reviews.llvm.org/D130988
2022-08-02 15:34:42 +02:00
set(powerpc64_SOURCES
Add powerpc64 to compiler-rt build infrastructure. Now that we have disabled the run-forever tests, and cleaned up the intel 80-bit float based tests, we should be able to enable testing compiler-rt for powerpc64. llvm-svn: 319474
2017-11-30 21:04:11 +00:00
ppc/divtc3.c
ppc/fixtfdi.c
ppc/fixunstfdi.c
ppc/floatditf.c
ppc/floatunditf.c
ppc/gcc_qadd.c
ppc/gcc_qdiv.c
ppc/gcc_qmul.c
ppc/gcc_qsub.c
ppc/multc3.c
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
${GENERIC_SOURCES}
)
[AIX][compiler-rt][builtins] Don't add ppc builtin implementations that require __int128 on AIX since __int128 currently isn't supported on AIX. Reviewed By: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D85972
2020-08-25 11:30:17 -04:00
# These routines require __int128, which isn't supported on AIX.
[compiler-rt] Move crt into builtins On Linux crt is typically use in combination with builtins. In the Clang driver the use of builtins and crt is controlled by the --rtlib option. Both builtins and crt also have similar build requirements where they need to be built before any other runtimes and must avoid dependencies. We also want builtins and crt these to be buildable separately from the rest of compiler-rt for bootstrapping purposes. Given how simple crt is, rather than maintaining a separate directory with its own separate build setup, it's more efficient to just move crt into builtins. We still use separate CMake option to control whether to built crt same as before. This is an alternative to D89492 and D136664. Differential Revision: https://reviews.llvm.org/D153989
2023-06-28 07:14:00 +00:00
if (NOT OS_NAME MATCHES "AIX")
Revert "[compiler-rt][CMake] Enable TF intrinsics on powerpc32 Linux" As mentioned in https://reviews.llvm.org/D121379#3690593, this change broke the build of compiler-rt targeting powerpc using GCC. The 32-bit powerpc target is not supposed to emit 128-bit libcalls -- if it does, then that's a backend bug and needs to be fixed there. This reverts commit 8f24a56a3a9363f353c8da318d97491a6818781d. Differential Revision: https://reviews.llvm.org/D130988
2022-08-02 15:34:42 +02:00
set(powerpc64_SOURCES
[AIX][compiler-rt][builtins] Don't add ppc builtin implementations that require __int128 on AIX since __int128 currently isn't supported on AIX. Reviewed By: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D85972
2020-08-25 11:30:17 -04:00
ppc/floattitf.c
ppc/fixtfti.c
ppc/fixunstfti.c
Revert "[compiler-rt][CMake] Enable TF intrinsics on powerpc32 Linux" As mentioned in https://reviews.llvm.org/D121379#3690593, this change broke the build of compiler-rt targeting powerpc using GCC. The 32-bit powerpc target is not supposed to emit 128-bit libcalls -- if it does, then that's a backend bug and needs to be fixed there. This reverts commit 8f24a56a3a9363f353c8da318d97491a6818781d. Differential Revision: https://reviews.llvm.org/D130988
2022-08-02 15:34:42 +02:00
${powerpc64_SOURCES}
[AIX][compiler-rt][builtins] Don't add ppc builtin implementations that require __int128 on AIX since __int128 currently isn't supported on AIX. Reviewed By: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D85972
2020-08-25 11:30:17 -04:00
)
endif()
Revert "[compiler-rt][CMake] Enable TF intrinsics on powerpc32 Linux" As mentioned in https://reviews.llvm.org/D121379#3690593, this change broke the build of compiler-rt targeting powerpc using GCC. The 32-bit powerpc target is not supposed to emit 128-bit libcalls -- if it does, then that's a backend bug and needs to be fixed there. This reverts commit 8f24a56a3a9363f353c8da318d97491a6818781d. Differential Revision: https://reviews.llvm.org/D130988
2022-08-02 15:34:42 +02:00
set(powerpc64le_SOURCES ${powerpc64_SOURCES})
Add powerpc64 to compiler-rt build infrastructure. Now that we have disabled the run-forever tests, and cleaned up the intel 80-bit float based tests, we should be able to enable testing compiler-rt for powerpc64. llvm-svn: 319474
2017-11-30 21:04:11 +00:00
[RISCV][compiler-rt] Add support for save-restore This adds the compiler-rt entry points required by the -msave-restore option. Differential Revision: https://reviews.llvm.org/D91717
2020-11-12 16:33:03 +00:00
set(riscv_SOURCES
[RISCV][compiler-rt] Small fixes for __riscv_feature_bits (#100158) Changes included: - Adding CONSTRUCTOR_ATTRIBUTE so that the static data is setup early on in process lifetime. This is required by gcc docs for __builtin_cpu_supports which we hope to implement in terms of this. - Move the length initialization outside of the #if defined(linux) block so that the length field always reflects the size of the structures even if non of the feature bits are non-zero. - Change the __riscv_vendor_feature_bits.length field to match the length of the actual structure. Note: Copy from https://github.com/llvm/llvm-project/pull/99958 --------- Co-authored-by: Philip Reames <preames@rivosinc.com>
2024-07-24 07:52:08 +08:00
cpu_model/riscv.c
[RISCV] Support fe_getround and fe_raise_inexact in builtins Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D128240
2022-08-08 09:57:43 +08:00
riscv/fp_mode.c
[RISCV][compiler-rt] Add support for save-restore This adds the compiler-rt entry points required by the -msave-restore option. Differential Revision: https://reviews.llvm.org/D91717
2020-11-12 16:33:03 +00:00
riscv/save.S
riscv/restore.S
${GENERIC_SOURCES}
${GENERIC_TF_SOURCES}
)
[PATCH] [compiler-rt, RISCV] Support builtins for RISC-V Summary: Support builtins for RISC-V, RV32 and RV64. Reviewers: asb, apazos, mgrang Differential Revision: https://reviews.llvm.org/D42958 llvm-svn: 326420
2018-03-01 07:47:27 +00:00
set(riscv32_SOURCES
riscv/mulsi3.S
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
${riscv_SOURCES}
)
[compiler-rt][RISCV] Use muldi3 builtin assembly implementation D80465 added an assembly implementation of muldi3 for RISC-V but it didn't add it to the cmake `*_SOURCES` list, so the C implementation was being used instead. This patch fixes that. Differential Revision: https://reviews.llvm.org/D86036
2020-08-21 13:04:25 +01:00
set(riscv64_SOURCES
riscv/muldi3.S
${riscv_SOURCES}
)
[PATCH] [compiler-rt, RISCV] Support builtins for RISC-V Summary: Support builtins for RISC-V, RV32 and RV64. Reviewers: asb, apazos, mgrang Differential Revision: https://reviews.llvm.org/D42958 llvm-svn: 326420
2018-03-01 07:47:27 +00:00
Enable compiler-rt on SPARC This patch enables compiler-rt on SPARC targets. Most of the changes are straightforward: - Add 32 and 64-bit sparc to compiler-rt - lib/builtins/fp_lib.h needed to check if the int128_t and uint128_t types exist (which they don't on sparc) There's one issue of note: many asan tests fail to compile on Solaris/SPARC: fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported. Therefore, while asan is still built, both asan and ubsan-with-asan testing is disabled. The goal is to check if asan keeps compiling on Solaris/SPARC. This serves asan in gcc, which doesn't have the problem above and works just fine. With this patch, sparcv9-sun-solaris2.11 test results are pretty good: Failing Tests (9): Builtins-sparc-sunos :: divtc3_test.c Builtins-sparcv9-sunos :: compiler_rt_logbl_test.c Builtins-sparcv9-sunos :: divtc3_test.c [...] UBSan-Standalone-sparc :: TestCases/TypeCheck/misaligned.cpp UBSan-Standalone-sparcv9 :: TestCases/TypeCheck/misaligned.cpp The builtin failures are due to Bugs 42493 and 42496. The tree contained a few additonal patches either currently in review or about to be submitted. Tested on sparcv9-sun-solaris2.11. Differential Revision: https://reviews.llvm.org/D40943 llvm-svn: 365880
2019-07-12 08:30:17 +00:00
set(sparc_SOURCES ${GENERIC_SOURCES} ${GENERIC_TF_SOURCES})
set(sparcv9_SOURCES ${GENERIC_SOURCES} ${GENERIC_TF_SOURCES})
[WebAssembly] Include GENERIC_TF_SOURCES in wasm builds Differential Revision: https://reviews.llvm.org/D39748 llvm-svn: 317601
2017-11-07 19:03:11 +00:00
set(wasm32_SOURCES
${GENERIC_TF_SOURCES}
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
${GENERIC_SOURCES}
)
[WebAssembly] Include GENERIC_TF_SOURCES in wasm builds Differential Revision: https://reviews.llvm.org/D39748 llvm-svn: 317601
2017-11-07 19:03:11 +00:00
set(wasm64_SOURCES
${GENERIC_TF_SOURCES}
[gn] Support for building compiler-rt builtins This is support for building compiler-rt builtins, The library build should be complete for a subset of supported platforms, but not all CMake options have been replicated in GN. We always use the just built compiler to build all the runtimes, which is equivalent to the CMake runtimes build. This simplifies the build configuration because we don't need to support arbitrary host compiler and can always assume the latest Clang. With GN's toolchain support, this is significantly more efficient than the CMake runtimes build. Differential Revision: https://reviews.llvm.org/D60331 llvm-svn: 357821
2019-04-05 21:30:40 +00:00
${GENERIC_SOURCES}
)
[WebAssembly] Enable the builtins library for WebAssembly. llvm-svn: 257619
2016-01-13 16:56:15 +00:00
[VE] Dynamic stack allocation Summary: This patch implements dynamic stack allocation for the VE target. Changes: * compiler-rt: `__ve_grow_stack` to request stack allocation on the VE. * VE: base pointer support, dynamic stack allocation. Differential Revision: https://reviews.llvm.org/D79084
2020-05-27 09:39:39 +02:00
set(ve_SOURCES
ve/grow_stack.S
ve/grow_stack_align.S
${GENERIC_TF_SOURCES}
${GENERIC_SOURCES})
[CMake] Add top-level target for each compiler-rt library, and add 'compiler-rt' target encompassing them all. llvm-svn: 201556
2014-02-18 09:33:45 +00:00
add_custom_target(builtins)
[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
set_target_properties(builtins PROPERTIES FOLDER "Compiler-RT/Metatargets")
[CMake] Add top-level target for each compiler-rt library, and add 'compiler-rt' target encompassing them all. llvm-svn: 201556
2014-02-18 09:33:45 +00:00
[builtins] Add option to always build int128 routines 32-bit targets don't build these by default, but e.g. armv7 and x86 can build them just fine, and it's useful to have the int128 routines available for certain applications. Add a CMake option to let us include the int128 routines for architectures which would otherwise lack them. Reviewed By: compnerd, MaskRay, phosek Differential Revision: https://reviews.llvm.org/D145003
2023-02-28 13:13:45 -08:00
option(COMPILER_RT_ENABLE_SOFTWARE_INT128
"Enable the int128 builtin routines for all targets."
OFF)
[CMake] Fix building builtins on Linux and Darwin. Summary: I broke building the builtins with r245967. This fixes them on Linux and builds them properly for Darwin. The old code could not be made to work on Darwin as a result of the refactoring of add_compiler_rt_runtime, so I had to rework the way they are built for Darwin. This solution is not ideal and will be fixed in subsequent commits. I just want to get this in so everything is working again. Reviewers: samsonov, chh, compnerd, bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12500 llvm-svn: 246487
2015-08-31 21:24:50 +00:00
if (APPLE)
[CMake] [Darwin] [builtins] Make CMake re-generate if the builtin filter lists change. We need to make sure that if you change the builtin filter lists CMake re-generates its configurations so it includes the right builtins in the generated libraries. llvm-svn: 248852
2015-09-29 23:21:07 +00:00
add_subdirectory(Darwin-excludes)
add_subdirectory(macho_embedded)
[CMake] [Darwin] Bug 21562 - Add a CMake equivalent for make/platform/clang_darwin.mk in compiler_rt Summary: Building the builtins on Darwin platforms is a bit complicated. This is a first-pass implementation of the functionality from clang_darwin.mk into CMake. When building the builtins on Darwin we have layers of blacklists that we apply based on platform, architecture, and minimum supported OS version. Reviewers: bogner, filcab, bob.wilson, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13059 llvm-svn: 248383
2015-09-23 15:18:17 +00:00
darwin_add_builtin_libraries(${BUILTIN_SUPPORTED_OS})
[CMake] Add partial support for MSVC in compiler-rt builtins, by Roman Shirokiy. This enables MSVC build of complex number arithmetic compiler-rt builtins. Differential Revision: http://reviews.llvm.org/D17452 llvm-svn: 261432
2016-02-20 12:56:04 +00:00
else ()
[compiler-rt] Use flags found when configuring builtins during compilation Summary: This fixes the omission of -fPIC when building the builtins. Reviewers: compnerd, beanz Subscribers: dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D23729 llvm-svn: 279469
2016-08-22 20:33:47 +00:00
set(BUILTIN_CFLAGS "")
[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_security_warnings(BUILTIN_CFLAGS 0)
builtins: ensure that VISIBILITY_HIDDEN is defined properly The CMake build system had missed this macro as part of the build of the builtins. This would result in the builtins exporting symbols which are implemented in assembly with global visibility. Ensure that the assembly optimized routines are given the same visibility as the C routines. llvm-svn: 285477
2016-10-28 23:19:03 +00:00
Control-flow Enforcement Technology (CET), published by Intel, introduces indirect branch tracking(IBT) feature aiming to ensure the target address of an indirect jump/call is not tampered. When IBT is enabled, each function or target of any indirect jump/call will start with an 'endbr32/64' instruction otherwise the program will crash during execution. To build an application with CET enabled. we need to ensure: 1. build the source code with "-fcf-protection=full" 2. all the libraries linked with .o files must be CET enabled too This patch aims to enable CET for compiler-rt builtins library, we add an option "COMPILER_RT_ENABLE_CET" whose default value is OFF to enable CET for compiler-rt in building time and when this option is "ON", "-fcf-protection=full" is added to BUILTINS_CFLAG and the "endbr32/64" will be placed in the beginning of each assembly function. We also enabled CET for crtbegin, crtend object files in this patch. Reviewed by: MaskRay, compnerd, manojgupta, efriedma Differential Revision: https://reviews.llvm.org/D109811 Signed-off-by: jinge90 <ge.jin@intel.com>
2022-01-10 09:23:28 +08:00
if (COMPILER_RT_HAS_FCF_PROTECTION_FLAG)
append_list_if(COMPILER_RT_ENABLE_CET -fcf-protection=full BUILTIN_CFLAGS)
endif()
Revert "[compiler-rt] Use C_STANDARD instead of custom logic for adding -std=c11" This reverts commit 2f251925db060f83894a4cf5448259b7a1255552. This was reported to break the Builtins-powerpc64le-linux::qdiv_test.c test on ppc64le buildbots, e.g. these: https://lab.llvm.org/buildbot/#/builders/105/builds/24538 https://lab.llvm.org/buildbot/#/builders/121/builds/18755
2022-04-27 00:19:14 +03:00
append_list_if(COMPILER_RT_HAS_STD_C11_FLAG -std=c11 BUILTIN_CFLAGS)
[builtins] Build with -Wbuiltin-declaration-mismatch if supported GCC is able to check that the signatures of the builtins are as expected and this shows some incorrect signatures on ld80 platforms (i.e. x86). The *tf* functions should take 128-bit arguments but until the latest fixes they used 80-bit long double. Differential Revision: https://reviews.llvm.org/D153814
2023-06-26 12:24:39 -07:00
append_list_if(COMPILER_RT_HAS_WBUILTIN_DECLARATION_MISMATCH_FLAG -Werror=builtin-declaration-mismatch BUILTIN_CFLAGS)
Revert "[compiler-rt] Use C_STANDARD instead of custom logic for adding -std=c11" This reverts commit 2f251925db060f83894a4cf5448259b7a1255552. This was reported to break the Builtins-powerpc64le-linux::qdiv_test.c test on ppc64le buildbots, e.g. these: https://lab.llvm.org/buildbot/#/builders/105/builds/24538 https://lab.llvm.org/buildbot/#/builders/121/builds/18755
2022-04-27 00:19:14 +03:00
[compiler-rt] Don't link builtins against the CRT on Windows (#70675) compiler-rt/builtins doesn't depend on anything from the CRT but currently links against it and embeds a `/defaultlib:msvcrt` in the `.lib` file, forcing anyone linking against it to also link against that specific CRT. This isn't necessary as the end user can just choose which CRT they want to use independently.
2023-10-31 12:51:38 +00:00
# Don't embed directives for picking any specific CRT
if (MSVC)
set(CMAKE_MSVC_RUNTIME_LIBRARY "")
append_list_if(COMPILER_RT_HAS_ZL_FLAG /Zl BUILTIN_CFLAGS)
endif()
[compiler-rt] Use flags found when configuring builtins during compilation Summary: This fixes the omission of -fPIC when building the builtins. Reviewers: compnerd, beanz Subscribers: dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D23729 llvm-svn: 279469
2016-08-22 20:33:47 +00:00
# These flags would normally be added to CMAKE_C_FLAGS by the llvm
# cmake step. Add them manually if this is a standalone build.
if(COMPILER_RT_STANDALONE_BUILD)
[CMake] compiler-rt: Add COMPILER_RT_BUILTINS_ENABLE_PIC The configuration for -fPIC in the builtins library when built standalone is unconditional, stating that the flags would "normally be added... by the llvm cmake step" This is untrue, as the llvm cmake step checks LLVM_ENABLE_PIC, which allows a client to turn off -fPIC. I've added an option when compiler-rt builtins are configured standalone, such as when built as part of the LLVM runtimes system, to guard the application of -fPIC for users that want it. Patch By: JamesNagurne Differential Revision: https://reviews.llvm.org/D72950
2020-01-31 15:57:18 -08:00
if(COMPILER_RT_BUILTINS_ENABLE_PIC)
append_list_if(COMPILER_RT_HAS_FPIC_FLAG -fPIC BUILTIN_CFLAGS)
endif()
[compiler-rt] Use flags found when configuring builtins during compilation Summary: This fixes the omission of -fPIC when building the builtins. Reviewers: compnerd, beanz Subscribers: dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D23729 llvm-svn: 279469
2016-08-22 20:33:47 +00:00
append_list_if(COMPILER_RT_HAS_FNO_BUILTIN_FLAG -fno-builtin BUILTIN_CFLAGS)
[builtins] Add COMPILER_RT_BUILTINS_HIDE_SYMBOLS On Android, when the builtins are linked into a binary, they are typically linked using -Wl,--exclude-libs so that the symbols aren't reexported. For the NDK, compiler-rt's default behavior (build the builtins archive with -fvisibility=hidden) is better so that builtins are hidden even without -Wl,--exclude-libs. Android needs the builtins with non-hidden symbols only for a special case: for backwards compatibility with old binaries, the libc.so and libm.so DSOs in the platform need to export some builtins for arm32 and 32-bit x86. See D56977. Control the behavior with a new flag, `COMPILER_RT_BUILTINS_HIDE_SYMBOLS`, that behaves similarly to the `*_HERMETIC_STATIC_LIBRARY` in libunwind/libcxx/libcxxabi, so that Android can build a special builtins variant for libc.so/libm.so. Unlike the hermetic flags for other projects, this new flag is enabled by default. Reviewed By: compnerd, MaskRay Differential Revision: https://reviews.llvm.org/D93431
2021-01-07 17:49:29 -08:00
if(COMPILER_RT_BUILTINS_HIDE_SYMBOLS)
[builtins] Do not set hidden attribute on Android Bionic libc relies on an old libgcc behaviour which does not set hidden visibility attribute. Keep exporting these symbols on Android for compatibility. Differential Revision: https://reviews.llvm.org/D56977 llvm-svn: 351915
2019-01-23 01:59:35 +00:00
append_list_if(COMPILER_RT_HAS_VISIBILITY_HIDDEN_FLAG -fvisibility=hidden BUILTIN_CFLAGS)
endif()
[compiler-rt] Use flags found when configuring builtins during compilation Summary: This fixes the omission of -fPIC when building the builtins. Reviewers: compnerd, beanz Subscribers: dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D23729 llvm-svn: 279469
2016-08-22 20:33:47 +00:00
if(NOT COMPILER_RT_DEBUG)
append_list_if(COMPILER_RT_HAS_OMIT_FRAME_POINTER_FLAG -fomit-frame-pointer BUILTIN_CFLAGS)
endif()
endif()
Silence "unrecognised -std=c99" warning on MSVC. Thanks to angelsl for the patch! Differential Revision: http://reviews.llvm.org/D13692 llvm-svn: 253646
2015-11-20 03:37:12 +00:00
[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
# Directly targeting the GPU requires a few extra flags.
if("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "amdgcn|nvptx")
append_list_if(COMPILER_RT_HAS_FFREESTANDING_FLAG -ffreestanding BUILTIN_CFLAGS)
append_list_if(COMPILER_RT_HAS_NOGPULIB_FLAG -nogpulib BUILTIN_CFLAGS)
append_list_if(COMPILER_RT_HAS_FLTO_FLAG -flto BUILTIN_CFLAGS)
append_list_if(COMPILER_RT_HAS_FCONVERGENT_FUNCTIONS_FLAG
-fconvergent-functions BUILTIN_CFLAGS)
[AMDGPU] Fix code object version not being set to 'none' (#135036) Summary: Previously, we removed the special handling for the code object version global. I erroneously thought that this meant we cold get rid of this weird `-Xclang` option. However, this also emits an LLVM IR module flag, which will then cause linking issues.
2025-04-10 11:31:21 -05:00
# AMDGPU targets want to use a generic ABI.
if("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "amdgcn")
append_list_if(COMPILER_RT_HAS_CODE_OBJECT_VERSION_FLAG
"SHELL:-Xclang -mcode-object-version=none" BUILTIN_CFLAGS)
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
endif()
builtins: ensure that VISIBILITY_HIDDEN is defined properly The CMake build system had missed this macro as part of the build of the builtins. This would result in the builtins exporting symbols which are implemented in assembly with global visibility. Ensure that the assembly optimized routines are given the same visibility as the C routines. llvm-svn: 285477
2016-10-28 23:19:03 +00:00
set(BUILTIN_DEFS "")
[builtins] Add COMPILER_RT_BUILTINS_HIDE_SYMBOLS On Android, when the builtins are linked into a binary, they are typically linked using -Wl,--exclude-libs so that the symbols aren't reexported. For the NDK, compiler-rt's default behavior (build the builtins archive with -fvisibility=hidden) is better so that builtins are hidden even without -Wl,--exclude-libs. Android needs the builtins with non-hidden symbols only for a special case: for backwards compatibility with old binaries, the libc.so and libm.so DSOs in the platform need to export some builtins for arm32 and 32-bit x86. See D56977. Control the behavior with a new flag, `COMPILER_RT_BUILTINS_HIDE_SYMBOLS`, that behaves similarly to the `*_HERMETIC_STATIC_LIBRARY` in libunwind/libcxx/libcxxabi, so that Android can build a special builtins variant for libc.so/libm.so. Unlike the hermetic flags for other projects, this new flag is enabled by default. Reviewed By: compnerd, MaskRay Differential Revision: https://reviews.llvm.org/D93431
2021-01-07 17:49:29 -08:00
if(COMPILER_RT_BUILTINS_HIDE_SYMBOLS)
[builtins] Do not set hidden attribute on Android Bionic libc relies on an old libgcc behaviour which does not set hidden visibility attribute. Keep exporting these symbols on Android for compatibility. Differential Revision: https://reviews.llvm.org/D56977 llvm-svn: 351915
2019-01-23 01:59:35 +00:00
append_list_if(COMPILER_RT_HAS_VISIBILITY_HIDDEN_FLAG VISIBILITY_HIDDEN BUILTIN_DEFS)
endif()
builtins: ensure that VISIBILITY_HIDDEN is defined properly The CMake build system had missed this macro as part of the build of the builtins. This would result in the builtins exporting symbols which are implemented in assembly with global visibility. Ensure that the assembly optimized routines are given the same visibility as the C routines. llvm-svn: 285477
2016-10-28 23:19:03 +00:00
[AArch64][compiler-rt] Option to build compiler-rt without FMV support. This commit adds compiler-rt cmake option COMPILER_RT_DISABLE_AARCH64_FMV which, when enabled, doesn't include function multiversioning features initilization code in 'builtins' build. Differential Revision: https://reviews.llvm.org/D141199
2022-12-30 13:34:45 +00:00
if(COMPILER_RT_DISABLE_AARCH64_FMV)
list(APPEND BUILTIN_DEFS DISABLE_AARCH64_FMV)
[compiler-rt][AArch64] Rewrite SME routines to all use __aarch64_cpu_features. (#119414) When #92921 added the `__arm_get_current_vg` functionality, it used the FMV feature bits mechanism rather than the mechanism that was previously added for SME which called `getauxval` on Linux platforms or `__aarch64_sme_accessible` required for baremetal libraries. It is better to always use `__aarch64_cpu_features`. For baremetal we still need to rely on `__arm_sme_accessible` to initialise the struct.
2024-12-11 15:53:17 +00:00
elseif(COMPILER_RT_BAREMETAL_BUILD)
list(APPEND BUILTIN_DEFS ENABLE_BAREMETAL_AARCH64_FMV)
[AArch64][compiler-rt] Option to build compiler-rt without FMV support. This commit adds compiler-rt cmake option COMPILER_RT_DISABLE_AARCH64_FMV which, when enabled, doesn't include function multiversioning features initilization code in 'builtins' build. Differential Revision: https://reviews.llvm.org/D141199
2022-12-30 13:34:45 +00:00
endif()
Re-apply "[CMake][compiler-rt][AArch64] Avoid preprocessing LSE builtins separately" aa772fc85e0f526615c78b9c3979c2be945a754c (D92530) has landed fixing relocations on Darwin. 3000c19df64f89ff319590f3a6e4d6b93d20983d (D93236) has landed working around an assembly parser bug on Darwin. Previous quick-fix d9697c2e6b153ac7dc40a69450d9b672f71b1029 (D93198) included in this commit. Invoking the preprocessor ourselves is fragile and would require us to replicate CMake's handling of definitions, compiler flags, etc for proper compatibility. In my toolchain builds this notably resulted in a bunch of warnings from unused flags as my CMAKE_C_FLAGS includes CPU-specific optimization options. Notably this part was already duplicating the logic for VISIBILITY_HIDDEN define. Instead, symlink the files and set the proper set of defines on each. This should also be faster as we avoid invoking the compiler multiple times. Fixes https://llvm.org/PR48494 Differential Revision: https://reviews.llvm.org/D93278
2020-12-15 08:15:58 +02:00
append_list_if(COMPILER_RT_HAS_ASM_LSE HAS_ASM_LSE BUILTIN_DEFS)
[CMake] Fix building builtins on Linux and Darwin. Summary: I broke building the builtins with r245967. This fixes them on Linux and builds them properly for Darwin. The old code could not be made to work on Darwin as a result of the refactoring of add_compiler_rt_runtime, so I had to rework the way they are built for Darwin. This solution is not ideal and will be fixed in subsequent commits. I just want to get this in so everything is working again. Reviewers: samsonov, chh, compnerd, bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12500 llvm-svn: 246487
2015-08-31 21:24:50 +00:00
foreach (arch ${BUILTIN_SUPPORTED_ARCH})
builtins: avoid multiple definitions of symbols The architecture specific implementation of routines would be built and included along with the generic implementation. This would result in multiple definitions of those symbols. The linker is free to select either of the two. Most of the time, this shouldn't be too terrible as the forward iteration should catch the architecture version due to the ordering. Rather than relying on the linker and build infrastructure ordering things in a specific manner, only provide the architecture version when available. This reduces the size of compiler-rt, simplifies inspection of the library implementations, and guarantees that the desired version is selected at a slightly complex build system. llvm-svn: 214040
2014-07-26 23:44:22 +00:00
if (CAN_TARGET_${arch})
[builtins] Only build float16/bfloat16 code if actually supported When building compiler-rt builtins for x86_64 they library will by default also be built for i386. We unconditionally add the Float16 compile flags since the check for Float16 support will be done using x86_64 compiler flags, but i386 does not actually support it. Fix this by moving the COMPILER_RT_HAS_FLOAT16 and COMPILER_RT_HAS_FLOAT16 checks to a per-target-architecture check inside the loop (using `check_c_source_compiles` and `cmake_{push,pop}_check_state`). Many of the checks in the builtin-config-ix file should probably also be changed to per-target-arch checks, but so far only the Float16 one has caused issues. This is an alternative to D136044 which added a special case for i386 FreeBSD. Fixes: https://github.com/llvm/llvm-project/issues/57224 Differential Revision: https://reviews.llvm.org/D145237
2023-03-03 13:54:08 +00:00
cmake_push_check_state()
# TODO: we should probably make most of the checks in builtin-config depend on the target flags.
[compiler-rt] Fix compilation when multiple architectures can be targeted When toolchain can supports all of arm, armhf and armv6m architectures compiler-rt libraries won't compile because architecture specific flags are appended to single BUILTIN_CFLAGS variable. Differential revision: https://reviews.llvm.org/D103363
2021-06-01 15:26:51 +03:00
set(BUILTIN_CFLAGS_${arch} ${BUILTIN_CFLAGS})
[compiler-rt][CMake] Pass all flags to _Float16 try-compile (#133952) The try-compile mechanism requires that `CMAKE_REQUIRED_FLAGS` is a space-separated string instead of a list of flags. The original code expanded `BUILTIN_FLAGS` into `CMAKE_REQUIRED_FLAGS` as a space-separated string and then would overwrite `CMAKE_REQUIRED_FLAGS` with `TARGET_${arch}_CFLAGS` prepended to the unexpanded `BUILTIN_CFLAGS_${arch}`. This resulted in the first two arguments being passed into the try-compile invocation, but dropping the other arguments listed in `BUILTIN_CFLAGS_${arch}`. This patch appends `TARGET_${arch}_CFLAGS` and `BUILTIN_CFLAGS_${arch}` to `CMAKE_REQUIRED_FLAGS` before expanding CMAKE_REQUIRED_FLAGS as a space-separated string. This passes any pre-set required flags, in addition to all of the builtin and target flags to the Float16 detection.
2025-04-04 09:02:24 -07:00
# CMAKE_REQUIRED_FLAGS must be a space separated string
# Join BUILTIN_CFLAGS_${arch} and TARGET_${arch}_CFLAGS as a
# space-separated string.
list(APPEND CMAKE_REQUIRED_FLAGS
${BUILTIN_CFLAGS_${arch}}
${TARGET_${arch}_CFLAGS})
list(JOIN CMAKE_REQUIRED_FLAGS " " CMAKE_REQUIRED_FLAGS)
[compiler-rt] Fix detecting _Float16 support for secondary targets (#117813) It turns out we were not passing -m32 to the check_c_source_compiles() invocation since CMAKE_REQUIRE_FLAGS needs to be string separated list and we were passing a ;-separated CMake list which appears to be parsed by CMake as 'ignore all arguments beyond the first'. Fix this by transforming the list to a command line first. With this change, Clang 17 no longer claims to support _Float16 for i386.
2024-11-28 10:42:47 -08:00
message(STATUS "Performing additional configure checks with target flags: ${CMAKE_REQUIRED_FLAGS}")
[cmake] [ARM] Exclude any VFP builtins if VFP is not supported Summary: rL325492 disables FPU features when using soft floating point (-mfloat-abi=soft), which is used internally when building for arm. This causes errors with builtins that utililize VFP instructions. With this change we check if VFP is enabled (by checking if the preprocessor macro __VFP_FP__ is defined), and exclude such builtins if it is not enabled. Reviewers: rengolin, samsonov, compnerd, smeenai, javed.absar, peter.smith Reviewed By: peter.smith Subscribers: delcypher, peter.smith, mgorny, kristof.beyls, chrib, llvm-commits Differential Revision: https://reviews.llvm.org/D47217 llvm-svn: 338284
2018-07-30 18:18:59 +00:00
# For ARM archs, exclude any VFP builtins if VFP is not supported
[arm][compiler-rt] add armv8m.main and arv8.1m.main targets These changes were enough to compile compiler-rt builtins for armv8m.main and armv8.1m.main. Differential Revision: https://reviews.llvm.org/D99600
2021-03-30 16:57:50 +01:00
if (${arch} MATCHES "^(arm|armhf|armv7|armv7s|armv7k|armv7m|armv7em|armv8m.main|armv8.1m.main)$")
[compiler-rt][CMake] Pass all flags to _Float16 try-compile (#133952) The try-compile mechanism requires that `CMAKE_REQUIRED_FLAGS` is a space-separated string instead of a list of flags. The original code expanded `BUILTIN_FLAGS` into `CMAKE_REQUIRED_FLAGS` as a space-separated string and then would overwrite `CMAKE_REQUIRED_FLAGS` with `TARGET_${arch}_CFLAGS` prepended to the unexpanded `BUILTIN_CFLAGS_${arch}`. This resulted in the first two arguments being passed into the try-compile invocation, but dropping the other arguments listed in `BUILTIN_CFLAGS_${arch}`. This patch appends `TARGET_${arch}_CFLAGS` and `BUILTIN_CFLAGS_${arch}` to `CMAKE_REQUIRED_FLAGS` before expanding CMAKE_REQUIRED_FLAGS as a space-separated string. This passes any pre-set required flags, in addition to all of the builtin and target flags to the Float16 detection.
2025-04-04 09:02:24 -07:00
check_compile_definition(__ARM_FP "${CMAKE_C_FLAGS}" COMPILER_RT_HAS_${arch}_VFP)
[cmake] [ARM] Exclude any VFP builtins if VFP is not supported Summary: rL325492 disables FPU features when using soft floating point (-mfloat-abi=soft), which is used internally when building for arm. This causes errors with builtins that utililize VFP instructions. With this change we check if VFP is enabled (by checking if the preprocessor macro __VFP_FP__ is defined), and exclude such builtins if it is not enabled. Reviewers: rengolin, samsonov, compnerd, smeenai, javed.absar, peter.smith Reviewed By: peter.smith Subscribers: delcypher, peter.smith, mgorny, kristof.beyls, chrib, llvm-commits Differential Revision: https://reviews.llvm.org/D47217 llvm-svn: 338284
2018-07-30 18:18:59 +00:00
if(NOT COMPILER_RT_HAS_${arch}_VFP)
[builtins] Add support for single-precision-only-FPU ARM targets. This patch enables building compiler-rt builtins for ARM targets that only support single-precision floating point instructions (e.g., those with -mfpu=fpv4-sp-d16). This fixes PR42838 Differential Revision: https://reviews.llvm.org/D90698
2020-11-12 14:44:54 +00:00
list(REMOVE_ITEM ${arch}_SOURCES ${arm_Thumb1_VFPv2_DP_SOURCES} ${arm_Thumb1_VFPv2_SP_SOURCES} ${arm_Thumb1_SjLj_EH_SOURCES})
else()
# Exclude any double-precision builtins if VFP is single-precision-only
[compiler-rt] Use try_compile_only to check for __ARM_FP This fixes detection when linking isn't supported (i.e. while building builtins the first time). Since 8368e4d54c459fe173d76277f17c632478e91add, after setting CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY, this isn't strictly needed, but is good for correctness anyway (and in case that commit ends up reverted). Differential Revision: https://reviews.llvm.org/D98737
2021-03-11 22:14:45 +02:00
try_compile_only(COMPILER_RT_HAS_${arch}_VFP_DP
SOURCE "#if !(__ARM_FP & 0x8)
[builtins] Add support for single-precision-only-FPU ARM targets. This patch enables building compiler-rt builtins for ARM targets that only support single-precision floating point instructions (e.g., those with -mfpu=fpv4-sp-d16). This fixes PR42838 Differential Revision: https://reviews.llvm.org/D90698
2020-11-12 14:44:54 +00:00
#error No double-precision support!
#endif
[CMake] Fix -Wstrict-prototypes Fixes warnings (or errors, if someone injects -Werror in their build system, which happens in fact with some folks vendoring LLVM too) with Clang 16: ``` +/var/tmp/portage.notmp/portage/sys-devel/llvm-15.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes] -/var/tmp/portage.notmp/portage/sys-devel/llvm-14.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] int main() {return 0;} ^ void ``` Differential Revision: https://reviews.llvm.org/D137503
2022-11-08 01:36:43 +00:00
int main(void) { return 0; }")
[builtins] Add support for single-precision-only-FPU ARM targets. This patch enables building compiler-rt builtins for ARM targets that only support single-precision floating point instructions (e.g., those with -mfpu=fpv4-sp-d16). This fixes PR42838 Differential Revision: https://reviews.llvm.org/D90698
2020-11-12 14:44:54 +00:00
if(NOT COMPILER_RT_HAS_${arch}_VFP_DP)
list(REMOVE_ITEM ${arch}_SOURCES ${arm_Thumb1_VFPv2_DP_SOURCES})
endif()
[cmake] [ARM] Exclude any VFP builtins if VFP is not supported Summary: rL325492 disables FPU features when using soft floating point (-mfloat-abi=soft), which is used internally when building for arm. This causes errors with builtins that utililize VFP instructions. With this change we check if VFP is enabled (by checking if the preprocessor macro __VFP_FP__ is defined), and exclude such builtins if it is not enabled. Reviewers: rengolin, samsonov, compnerd, smeenai, javed.absar, peter.smith Reviewed By: peter.smith Subscribers: delcypher, peter.smith, mgorny, kristof.beyls, chrib, llvm-commits Differential Revision: https://reviews.llvm.org/D47217 llvm-svn: 338284
2018-07-30 18:18:59 +00:00
endif()
endif()
[builtins] Fix missing main() function in float16/bfloat16 support checks (#104478) The CMake docs state that `check_c_source_compiles()` checks whether the supplied code "can be compiled as a C source file and linked as an executable (so it must contain at least a `main()` function)." https://cmake.org/cmake/help/v3.30/module/CheckCSourceCompiles.html In practice, this command is a wrapper around `try_compile()`: - https://gitlab.kitware.com/cmake/cmake/blob/2904ce00d2ed6ad5dac6d3459af62d8223e06ce0/Modules/CheckCSourceCompiles.cmake#L54 - https://gitlab.kitware.com/cmake/cmake/blob/2904ce00d2ed6ad5dac6d3459af62d8223e06ce0/Modules/Internal/CheckSourceCompiles.cmake#L101 When `CMAKE_SOURCE_DIR` is compiler-rt/lib/builtins/, `CMAKE_TRY_COMPILE_TARGET_TYPE` is set to `STATIC_LIBRARY`, so the checks for `float16` and `bfloat16` support work as intended in a Clang + compiler-rt runtime build for example, as it runs CMake recursively from that directory. However, when using llvm/ or compiler-rt/ as CMake source directory, as `CMAKE_TRY_COMPILE_TARGET_TYPE` defaults to `EXECUTABLE`, these checks will indeed fail if the code doesn't have a `main()` function. This results in LLVM using x86 SIMD registers when generating calls to builtins that, with Arch Linux's compiler-rt package for example, actually use a GPR for their argument or return value as they use `uint16_t` instead of `_Float16`. This had been caught in post-commit review: https://reviews.llvm.org/D145237#4521152. Use of the internal `CMAKE_C_COMPILER_WORKS` variable is not what hides the issue, however. PR #69842 tried to fix this by unconditionally setting `CMAKE_TRY_COMPILE_TARGET_TYPE` to `STATIC_LIBRARY`, but it apparently caused other issues, so it was reverted. This PR just adds a `main()` function in the checks, as per the CMake docs.
2024-08-30 12:59:05 +02:00
check_c_source_compiles("_Float16 foo(_Float16 x) { return x; }
int main(void) { return 0; }"
[builtins] Only build float16/bfloat16 code if actually supported When building compiler-rt builtins for x86_64 they library will by default also be built for i386. We unconditionally add the Float16 compile flags since the check for Float16 support will be done using x86_64 compiler flags, but i386 does not actually support it. Fix this by moving the COMPILER_RT_HAS_FLOAT16 and COMPILER_RT_HAS_FLOAT16 checks to a per-target-architecture check inside the loop (using `check_c_source_compiles` and `cmake_{push,pop}_check_state`). Many of the checks in the builtin-config-ix file should probably also be changed to per-target-arch checks, but so far only the Float16 one has caused issues. This is an alternative to D136044 which added a special case for i386 FreeBSD. Fixes: https://github.com/llvm/llvm-project/issues/57224 Differential Revision: https://reviews.llvm.org/D145237
2023-03-03 13:54:08 +00:00
COMPILER_RT_HAS_${arch}_FLOAT16)
append_list_if(COMPILER_RT_HAS_${arch}_FLOAT16 -DCOMPILER_RT_HAS_FLOAT16 BUILTIN_CFLAGS_${arch})
[builtins] Fix missing main() function in float16/bfloat16 support checks (#104478) The CMake docs state that `check_c_source_compiles()` checks whether the supplied code "can be compiled as a C source file and linked as an executable (so it must contain at least a `main()` function)." https://cmake.org/cmake/help/v3.30/module/CheckCSourceCompiles.html In practice, this command is a wrapper around `try_compile()`: - https://gitlab.kitware.com/cmake/cmake/blob/2904ce00d2ed6ad5dac6d3459af62d8223e06ce0/Modules/CheckCSourceCompiles.cmake#L54 - https://gitlab.kitware.com/cmake/cmake/blob/2904ce00d2ed6ad5dac6d3459af62d8223e06ce0/Modules/Internal/CheckSourceCompiles.cmake#L101 When `CMAKE_SOURCE_DIR` is compiler-rt/lib/builtins/, `CMAKE_TRY_COMPILE_TARGET_TYPE` is set to `STATIC_LIBRARY`, so the checks for `float16` and `bfloat16` support work as intended in a Clang + compiler-rt runtime build for example, as it runs CMake recursively from that directory. However, when using llvm/ or compiler-rt/ as CMake source directory, as `CMAKE_TRY_COMPILE_TARGET_TYPE` defaults to `EXECUTABLE`, these checks will indeed fail if the code doesn't have a `main()` function. This results in LLVM using x86 SIMD registers when generating calls to builtins that, with Arch Linux's compiler-rt package for example, actually use a GPR for their argument or return value as they use `uint16_t` instead of `_Float16`. This had been caught in post-commit review: https://reviews.llvm.org/D145237#4521152. Use of the internal `CMAKE_C_COMPILER_WORKS` variable is not what hides the issue, however. PR #69842 tried to fix this by unconditionally setting `CMAKE_TRY_COMPILE_TARGET_TYPE` to `STATIC_LIBRARY`, but it apparently caused other issues, so it was reverted. This PR just adds a `main()` function in the checks, as per the CMake docs.
2024-08-30 12:59:05 +02:00
check_c_source_compiles("__bf16 foo(__bf16 x) { return x; }
int main(void) { return 0; }"
[builtins] Only build float16/bfloat16 code if actually supported When building compiler-rt builtins for x86_64 they library will by default also be built for i386. We unconditionally add the Float16 compile flags since the check for Float16 support will be done using x86_64 compiler flags, but i386 does not actually support it. Fix this by moving the COMPILER_RT_HAS_FLOAT16 and COMPILER_RT_HAS_FLOAT16 checks to a per-target-architecture check inside the loop (using `check_c_source_compiles` and `cmake_{push,pop}_check_state`). Many of the checks in the builtin-config-ix file should probably also be changed to per-target-arch checks, but so far only the Float16 one has caused issues. This is an alternative to D136044 which added a special case for i386 FreeBSD. Fixes: https://github.com/llvm/llvm-project/issues/57224 Differential Revision: https://reviews.llvm.org/D145237
2023-03-03 13:54:08 +00:00
COMPILER_RT_HAS_${arch}_BFLOAT16)
# Build BF16 files only when "__bf16" is available.
if(COMPILER_RT_HAS_${arch}_BFLOAT16)
list(APPEND ${arch}_SOURCES ${BF16_SOURCES})
endif()
[cmake] [ARM] Exclude any VFP builtins if VFP is not supported Summary: rL325492 disables FPU features when using soft floating point (-mfloat-abi=soft), which is used internally when building for arm. This causes errors with builtins that utililize VFP instructions. With this change we check if VFP is enabled (by checking if the preprocessor macro __VFP_FP__ is defined), and exclude such builtins if it is not enabled. Reviewers: rengolin, samsonov, compnerd, smeenai, javed.absar, peter.smith Reviewed By: peter.smith Subscribers: delcypher, peter.smith, mgorny, kristof.beyls, chrib, llvm-commits Differential Revision: https://reviews.llvm.org/D47217 llvm-svn: 338284
2018-07-30 18:18:59 +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
# Remove a generic C builtin when an arch-specific builtin is specified.
filter_builtin_sources(${arch}_SOURCES ${arch})
builtins: avoid multiple definitions of symbols The architecture specific implementation of routines would be built and included along with the generic implementation. This would result in multiple definitions of those symbols. The linker is free to select either of the two. Most of the time, this shouldn't be too terrible as the forward iteration should catch the architecture version due to the ordering. Rather than relying on the linker and build infrastructure ordering things in a specific manner, only provide the architecture version when available. This reduces the size of compiler-rt, simplifies inspection of the library implementations, and guarantees that the desired version is selected at a slightly complex build system. llvm-svn: 214040
2014-07-26 23:44:22 +00:00
[ARM RT] Fix broken clear_cache debug build on ARM clear_cache is using R7 for the SVC call and that's the frame pointer in GCC, which is only disabled on -O2/3, so Release builds finish, Debug don't. Fixes PR30797. llvm-svn: 285204
2016-10-26 15:20:33 +00:00
# Needed for clear_cache on debug mode, due to r7's usage in inline asm.
# Release mode already sets it via -O2/3, Debug mode doesn't.
if (${arch} STREQUAL "armhf")
[compiler-rt] Fix compilation when multiple architectures can be targeted When toolchain can supports all of arm, armhf and armv6m architectures compiler-rt libraries won't compile because architecture specific flags are appended to single BUILTIN_CFLAGS variable. Differential revision: https://reviews.llvm.org/D103363
2021-06-01 15:26:51 +03:00
list(APPEND BUILTIN_CFLAGS_${arch} -fomit-frame-pointer -DCOMPILER_RT_ARMHF_TARGET)
[ARM RT] Fix broken clear_cache debug build on ARM clear_cache is using R7 for the SVC call and that's the frame pointer in GCC, which is only disabled on -O2/3, so Release builds finish, Debug don't. Fixes PR30797. llvm-svn: 285204
2016-10-26 15:20:33 +00:00
endif()
Revert "[compiler-rt][CMake] Enable TF intrinsics on powerpc32 Linux" As mentioned in https://reviews.llvm.org/D121379#3690593, this change broke the build of compiler-rt targeting powerpc using GCC. The 32-bit powerpc target is not supposed to emit 128-bit libcalls -- if it does, then that's a backend bug and needs to be fixed there. This reverts commit 8f24a56a3a9363f353c8da318d97491a6818781d. Differential Revision: https://reviews.llvm.org/D130988
2022-08-02 15:34:42 +02:00
# For RISCV32, we must force enable int128 for compiling long
# double routines.
[builtins] Add option to always build int128 routines 32-bit targets don't build these by default, but e.g. armv7 and x86 can build them just fine, and it's useful to have the int128 routines available for certain applications. Add a CMake option to let us include the int128 routines for architectures which would otherwise lack them. Reviewed By: compnerd, MaskRay, phosek Differential Revision: https://reviews.llvm.org/D145003
2023-02-28 13:13:45 -08:00
if(COMPILER_RT_ENABLE_SOFTWARE_INT128 OR "${arch}" STREQUAL "riscv32")
[compiler-rt] Fix compilation when multiple architectures can be targeted When toolchain can supports all of arm, armhf and armv6m architectures compiler-rt libraries won't compile because architecture specific flags are appended to single BUILTIN_CFLAGS variable. Differential revision: https://reviews.llvm.org/D103363
2021-06-01 15:26:51 +03:00
list(APPEND BUILTIN_CFLAGS_${arch} -fforce-enable-int128)
[RISCV] Force enable int128 for compiling long double routines Summary: For RISCV32, we must force enable int128 for compiling long double routines using the flag -fforce-enable-int128. Related clang patch: https://reviews.llvm.org/D43105 Reviewers: asb, kito-cheng, apazos, compnerd, howard.hinnant Reviewed By: kito-cheng Subscribers: shiva0217, efriedma, mgorny, hintonda, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D43106 llvm-svn: 326346
2018-02-28 18:24:09 +00:00
endif()
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-25 19:53:09 +00:00
add_compiler_rt_runtime(clang_rt.builtins
STATIC
[CMake] Fix building builtins on Linux and Darwin. Summary: I broke building the builtins with r245967. This fixes them on Linux and builds them properly for Darwin. The old code could not be made to work on Darwin as a result of the refactoring of add_compiler_rt_runtime, so I had to rework the way they are built for Darwin. This solution is not ideal and will be fixed in subsequent commits. I just want to get this in so everything is working again. Reviewers: samsonov, chh, compnerd, bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12500 llvm-svn: 246487
2015-08-31 21:24:50 +00:00
ARCHS ${arch}
[compiler-rt][CMake][arm64] Use a custom target for symlinking LSE sources On Apple platforms the builtins may be built for both arm64 and arm64e. With Makefile generators separate targets are built using Make sub-invocations. This causes a race when creating the symlink which may sometimes fail. Work around this by using a custom target that the builtin targets depend on. This causes any sub-invocations to depend on the symlinks having been created before. Mailing list thread: https://lists.llvm.org/pipermail/llvm-dev/2021-July/151822.html Reviewed By: thakis, steven_wu Differential Revision: https://reviews.llvm.org/D106305
2021-07-21 20:38:24 +03:00
DEPS ${deps_${arch}}
builtins: avoid multiple definitions of symbols The architecture specific implementation of routines would be built and included along with the generic implementation. This would result in multiple definitions of those symbols. The linker is free to select either of the two. Most of the time, this shouldn't be too terrible as the forward iteration should catch the architecture version due to the ordering. Rather than relying on the linker and build infrastructure ordering things in a specific manner, only provide the architecture version when available. This reduces the size of compiler-rt, simplifies inspection of the library implementations, and guarantees that the desired version is selected at a slightly complex build system. llvm-svn: 214040
2014-07-26 23:44:22 +00:00
SOURCES ${${arch}_SOURCES}
builtins: ensure that VISIBILITY_HIDDEN is defined properly The CMake build system had missed this macro as part of the build of the builtins. This would result in the builtins exporting symbols which are implemented in assembly with global visibility. Ensure that the assembly optimized routines are given the same visibility as the C routines. llvm-svn: 285477
2016-10-28 23:19:03 +00:00
DEFS ${BUILTIN_DEFS}
[compiler-rt] Fix compilation when multiple architectures can be targeted When toolchain can supports all of arm, armhf and armv6m architectures compiler-rt libraries won't compile because architecture specific flags are appended to single BUILTIN_CFLAGS variable. Differential revision: https://reviews.llvm.org/D103363
2021-06-01 15:26:51 +03:00
CFLAGS ${BUILTIN_CFLAGS_${arch}}
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-25 19:53:09 +00:00
PARENT_TARGET builtins)
[builtins] Only build float16/bfloat16 code if actually supported When building compiler-rt builtins for x86_64 they library will by default also be built for i386. We unconditionally add the Float16 compile flags since the check for Float16 support will be done using x86_64 compiler flags, but i386 does not actually support it. Fix this by moving the COMPILER_RT_HAS_FLOAT16 and COMPILER_RT_HAS_FLOAT16 checks to a per-target-architecture check inside the loop (using `check_c_source_compiles` and `cmake_{push,pop}_check_state`). Many of the checks in the builtin-config-ix file should probably also be changed to per-target-arch checks, but so far only the Float16 one has caused issues. This is an alternative to D136044 which added a special case for i386 FreeBSD. Fixes: https://github.com/llvm/llvm-project/issues/57224 Differential Revision: https://reviews.llvm.org/D145237
2023-03-03 13:54:08 +00:00
cmake_pop_check_state()
builtins: avoid multiple definitions of symbols The architecture specific implementation of routines would be built and included along with the generic implementation. This would result in multiple definitions of those symbols. The linker is free to select either of the two. Most of the time, this shouldn't be too terrible as the forward iteration should catch the architecture version due to the ordering. Rather than relying on the linker and build infrastructure ordering things in a specific manner, only provide the architecture version when available. This reduces the size of compiler-rt, simplifies inspection of the library implementations, and guarantees that the desired version is selected at a slightly complex build system. llvm-svn: 214040
2014-07-26 23:44:22 +00:00
endif ()
endforeach ()
endif ()
[CMake] Add top-level target for each compiler-rt library, and add 'compiler-rt' target encompassing them all. llvm-svn: 201556
2014-02-18 09:33:45 +00:00
[compiler-rt] Move crt into builtins On Linux crt is typically use in combination with builtins. In the Clang driver the use of builtins and crt is controlled by the --rtlib option. Both builtins and crt also have similar build requirements where they need to be built before any other runtimes and must avoid dependencies. We also want builtins and crt these to be buildable separately from the rest of compiler-rt for bootstrapping purposes. Given how simple crt is, rather than maintaining a separate directory with its own separate build setup, it's more efficient to just move crt into builtins. We still use separate CMake option to control whether to built crt same as before. This is an alternative to D89492 and D136664. Differential Revision: https://reviews.llvm.org/D153989
2023-06-28 07:14:00 +00:00
add_dependencies(compiler-rt builtins)
[AIX][compiler-rt] Build and install standalone libatomic On AIX, we have to ship `libatomic.a` for compatibility. First, a new `clang_rt.atomic` is added. Second, use added cmake modules for AIX, we are able to build a compatible libatomic.a for AIX. The second step can't be perfectly implemented with cmake now since AIX's archive approach is kinda unique, i.e., archiving shared libraries into a static archive file. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D102155
2021-05-16 05:03:10 +00:00
option(COMPILER_RT_BUILD_STANDALONE_LIBATOMIC
"Build standalone shared atomic library."
OFF)
if(COMPILER_RT_BUILD_STANDALONE_LIBATOMIC)
add_custom_target(builtins-standalone-atomic)
[AIX][compiler-rt] Fix cmake build of libatomic for cmake-3.16+ cmake-3.16+ for AIX changes the default behavior of building a `SHARED` library which breaks AIX's build of libatomic, i.e., cmake-3.16+ builds `SHARED` as an archive of dynamic libraries. To fix it, we have to build `libatomic.so.1` as `MODULE` which keeps `libatomic.so.1` as an normal dynamic library. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D103786
2021-06-11 23:21:40 +00:00
set(BUILTIN_TYPE SHARED)
[compiler-rt] Move crt into builtins On Linux crt is typically use in combination with builtins. In the Clang driver the use of builtins and crt is controlled by the --rtlib option. Both builtins and crt also have similar build requirements where they need to be built before any other runtimes and must avoid dependencies. We also want builtins and crt these to be buildable separately from the rest of compiler-rt for bootstrapping purposes. Given how simple crt is, rather than maintaining a separate directory with its own separate build setup, it's more efficient to just move crt into builtins. We still use separate CMake option to control whether to built crt same as before. This is an alternative to D89492 and D136664. Differential Revision: https://reviews.llvm.org/D153989
2023-06-28 07:14:00 +00:00
if(OS_NAME MATCHES "AIX")
include(CompilerRTAIXUtils)
[AIX][compiler-rt] Build and install standalone libatomic On AIX, we have to ship `libatomic.a` for compatibility. First, a new `clang_rt.atomic` is added. Second, use added cmake modules for AIX, we are able to build a compatible libatomic.a for AIX. The second step can't be perfectly implemented with cmake now since AIX's archive approach is kinda unique, i.e., archiving shared libraries into a static archive file. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D102155
2021-05-16 05:03:10 +00:00
if(NOT COMPILER_RT_LIBATOMIC_LINK_FLAGS)
get_aix_libatomic_default_link_flags(COMPILER_RT_LIBATOMIC_LINK_FLAGS
"${CMAKE_CURRENT_SOURCE_DIR}/ppc/atomic.exp")
endif()
[AIX][compiler-rt] Fix cmake build of libatomic for cmake-3.16+ cmake-3.16+ for AIX changes the default behavior of building a `SHARED` library which breaks AIX's build of libatomic, i.e., cmake-3.16+ builds `SHARED` as an archive of dynamic libraries. To fix it, we have to build `libatomic.so.1` as `MODULE` which keeps `libatomic.so.1` as an normal dynamic library. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D103786
2021-06-11 23:21:40 +00:00
# For different versions of cmake, SHARED behaves differently. For some
# versions, we might need MODULE rather than SHARED.
get_aix_libatomic_type(BUILTIN_TYPE)
[compiler-rt][bultins] Fix libatomic standalone build Differential Revision: https://reviews.llvm.org/D151679
2023-05-30 18:19:00 +00:00
else()
list(APPEND COMPILER_RT_LIBATOMIC_LINK_FLAGS -nodefaultlibs)
[AIX][compiler-rt] Build and install standalone libatomic On AIX, we have to ship `libatomic.a` for compatibility. First, a new `clang_rt.atomic` is added. Second, use added cmake modules for AIX, we are able to build a compatible libatomic.a for AIX. The second step can't be perfectly implemented with cmake now since AIX's archive approach is kinda unique, i.e., archiving shared libraries into a static archive file. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D102155
2021-05-16 05:03:10 +00:00
endif()
foreach (arch ${BUILTIN_SUPPORTED_ARCH})
if(CAN_TARGET_${arch})
[compiler-rt] Fix linking a standalone libatomic for MinGW (#74668) Whenever linking with -nodefaultlibs for a MinGW target, we manually need to specify a bunch of libraries - listed in ${MINGW_LIBRARIES}; the same is already done for sanitizers and libunwind/libcxxabi/libcxx. Practically speaking, linking with -nodefaultlibs but manually passing the libraries in ${MINGW_LIBRARIES} restores most of the libraries that are linked by default, except for the potential compiler builtins and unwind library; i.e. it has essentially the same effect as linking with "--unwindlib=none -rtlib=none", except that -rtlib doesn't accept such a value. When building only compiler-rt/lib/builtins, not all of compiler-rt, ${MINGW_LIBRARIES} is unset - set it manually here for that case. This matches what is set in compiler-rt/cmake/config-ix.cmake, except that the builtins (libgcc or compiler-rt builtins) is omitted; the only use within lib/buitlins is for the standalone libatomic, which explicitly already links against the just-built builtins.
2023-12-07 13:25:24 +02:00
list(APPEND COMPILER_RT_LIBATOMIC_LINK_LIBS_${arch} clang_rt.builtins-${arch})
append_list_if(MINGW "${MINGW_LIBRARIES}" COMPILER_RT_LIBATOMIC_LINK_LIBS_${arch})
[AIX][compiler-rt] Build and install standalone libatomic On AIX, we have to ship `libatomic.a` for compatibility. First, a new `clang_rt.atomic` is added. Second, use added cmake modules for AIX, we are able to build a compatible libatomic.a for AIX. The second step can't be perfectly implemented with cmake now since AIX's archive approach is kinda unique, i.e., archiving shared libraries into a static archive file. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D102155
2021-05-16 05:03:10 +00:00
add_compiler_rt_runtime(clang_rt.atomic
[AIX][compiler-rt] Fix cmake build of libatomic for cmake-3.16+ cmake-3.16+ for AIX changes the default behavior of building a `SHARED` library which breaks AIX's build of libatomic, i.e., cmake-3.16+ builds `SHARED` as an archive of dynamic libraries. To fix it, we have to build `libatomic.so.1` as `MODULE` which keeps `libatomic.so.1` as an normal dynamic library. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D103786
2021-06-11 23:21:40 +00:00
${BUILTIN_TYPE}
[AIX][compiler-rt] Build and install standalone libatomic On AIX, we have to ship `libatomic.a` for compatibility. First, a new `clang_rt.atomic` is added. Second, use added cmake modules for AIX, we are able to build a compatible libatomic.a for AIX. The second step can't be perfectly implemented with cmake now since AIX's archive approach is kinda unique, i.e., archiving shared libraries into a static archive file. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D102155
2021-05-16 05:03:10 +00:00
ARCHS ${arch}
SOURCES atomic.c
LINK_FLAGS ${COMPILER_RT_LIBATOMIC_LINK_FLAGS}
[compiler-rt] Fix linking a standalone libatomic for MinGW (#74668) Whenever linking with -nodefaultlibs for a MinGW target, we manually need to specify a bunch of libraries - listed in ${MINGW_LIBRARIES}; the same is already done for sanitizers and libunwind/libcxxabi/libcxx. Practically speaking, linking with -nodefaultlibs but manually passing the libraries in ${MINGW_LIBRARIES} restores most of the libraries that are linked by default, except for the potential compiler builtins and unwind library; i.e. it has essentially the same effect as linking with "--unwindlib=none -rtlib=none", except that -rtlib doesn't accept such a value. When building only compiler-rt/lib/builtins, not all of compiler-rt, ${MINGW_LIBRARIES} is unset - set it manually here for that case. This matches what is set in compiler-rt/cmake/config-ix.cmake, except that the builtins (libgcc or compiler-rt builtins) is omitted; the only use within lib/buitlins is for the standalone libatomic, which explicitly already links against the just-built builtins.
2023-12-07 13:25:24 +02:00
LINK_LIBS ${COMPILER_RT_LIBATOMIC_LINK_LIBS_${arch}}
[AIX][compiler-rt] Build and install standalone libatomic On AIX, we have to ship `libatomic.a` for compatibility. First, a new `clang_rt.atomic` is added. Second, use added cmake modules for AIX, we are able to build a compatible libatomic.a for AIX. The second step can't be perfectly implemented with cmake now since AIX's archive approach is kinda unique, i.e., archiving shared libraries into a static archive file. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D102155
2021-05-16 05:03:10 +00:00
PARENT_TARGET builtins-standalone-atomic)
endif()
endforeach()
# FIXME: On AIX, we have to archive built shared libraries into a static
# archive, i.e., libatomic.a. Once cmake adds support of such usage for AIX,
# this ad-hoc part can be removed.
[compiler-rt] Move crt into builtins On Linux crt is typically use in combination with builtins. In the Clang driver the use of builtins and crt is controlled by the --rtlib option. Both builtins and crt also have similar build requirements where they need to be built before any other runtimes and must avoid dependencies. We also want builtins and crt these to be buildable separately from the rest of compiler-rt for bootstrapping purposes. Given how simple crt is, rather than maintaining a separate directory with its own separate build setup, it's more efficient to just move crt into builtins. We still use separate CMake option to control whether to built crt same as before. This is an alternative to D89492 and D136664. Differential Revision: https://reviews.llvm.org/D153989
2023-06-28 07:14:00 +00:00
if(OS_NAME MATCHES "AIX")
[AIX][cmake][NFC] Customize name of output atomic library Let `archive-aix-libatomic` accept additional argument to customize name of output atomic library. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D120534
2022-02-28 02:27:26 +00:00
archive_aix_libatomic(clang_rt.atomic libatomic
[AIX][compiler-rt] Build and install standalone libatomic On AIX, we have to ship `libatomic.a` for compatibility. First, a new `clang_rt.atomic` is added. Second, use added cmake modules for AIX, we are able to build a compatible libatomic.a for AIX. The second step can't be perfectly implemented with cmake now since AIX's archive approach is kinda unique, i.e., archiving shared libraries into a static archive file. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D102155
2021-05-16 05:03:10 +00:00
ARCHS ${BUILTIN_SUPPORTED_ARCH}
PARENT_TARGET builtins-standalone-atomic)
endif()
add_dependencies(compiler-rt builtins-standalone-atomic)
endif()
[compiler-rt] Move crt into builtins On Linux crt is typically use in combination with builtins. In the Clang driver the use of builtins and crt is controlled by the --rtlib option. Both builtins and crt also have similar build requirements where they need to be built before any other runtimes and must avoid dependencies. We also want builtins and crt these to be buildable separately from the rest of compiler-rt for bootstrapping purposes. Given how simple crt is, rather than maintaining a separate directory with its own separate build setup, it's more efficient to just move crt into builtins. We still use separate CMake option to control whether to built crt same as before. This is an alternative to D89492 and D136664. Differential Revision: https://reviews.llvm.org/D153989
2023-06-28 07:14:00 +00:00
cmake_dependent_option(COMPILER_RT_BUILD_CRT "Build crtbegin.o/crtend.o" ON "COMPILER_RT_HAS_CRT" OFF)
[CMake] Use COMPILER_RT_BUILD_CRT in the condition for test Unlike COMPILER_RT_HAS_CRT this handles the case where CRT is available but has been disabled by setting COMPILER_RT_BUILD_CRT. This addresses an issue reported on D153989. Differential Revision: https://reviews.llvm.org/D155126
2023-07-12 17:41:16 +00:00
if (COMPILER_RT_BUILD_CRT)
[compiler-rt] Move crt into builtins On Linux crt is typically use in combination with builtins. In the Clang driver the use of builtins and crt is controlled by the --rtlib option. Both builtins and crt also have similar build requirements where they need to be built before any other runtimes and must avoid dependencies. We also want builtins and crt these to be buildable separately from the rest of compiler-rt for bootstrapping purposes. Given how simple crt is, rather than maintaining a separate directory with its own separate build setup, it's more efficient to just move crt into builtins. We still use separate CMake option to control whether to built crt same as before. This is an alternative to D89492 and D136664. Differential Revision: https://reviews.llvm.org/D153989
2023-06-28 07:14:00 +00:00
add_compiler_rt_component(crt)
Revert "[builtins] Disable COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY by d… (#84580) …efault (#83201)" This reverts commit 062cfada643c1aa48a1bb81894e2920d390fe8cf. See issue #84574.
2024-03-08 15:13:20 -08:00
option(COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY "Use eh_frame in crtbegin.o/crtend.o" ON)
[compiler-rt] Move crt into builtins On Linux crt is typically use in combination with builtins. In the Clang driver the use of builtins and crt is controlled by the --rtlib option. Both builtins and crt also have similar build requirements where they need to be built before any other runtimes and must avoid dependencies. We also want builtins and crt these to be buildable separately from the rest of compiler-rt for bootstrapping purposes. Given how simple crt is, rather than maintaining a separate directory with its own separate build setup, it's more efficient to just move crt into builtins. We still use separate CMake option to control whether to built crt same as before. This is an alternative to D89492 and D136664. Differential Revision: https://reviews.llvm.org/D153989
2023-06-28 07:14:00 +00:00
include(CheckSectionExists)
check_section_exists(".init_array" COMPILER_RT_HAS_INITFINI_ARRAY
SOURCE "volatile int x;\n__attribute__((constructor)) void f(void) {x = 0;}\nint main(void) { return 0; }\n")
append_list_if(COMPILER_RT_HAS_STD_C11_FLAG -std=c11 CRT_CFLAGS)
append_list_if(COMPILER_RT_HAS_INITFINI_ARRAY -DCRT_HAS_INITFINI_ARRAY CRT_CFLAGS)
append_list_if(COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY -DEH_USE_FRAME_REGISTRY CRT_CFLAGS)
append_list_if(COMPILER_RT_HAS_FPIC_FLAG -fPIC CRT_CFLAGS)
append_list_if(COMPILER_RT_HAS_WNO_PEDANTIC -Wno-pedantic CRT_CFLAGS)
if (COMPILER_RT_HAS_FCF_PROTECTION_FLAG)
append_list_if(COMPILER_RT_ENABLE_CET -fcf-protection=full CRT_CFLAGS)
endif()
foreach(arch ${BUILTIN_SUPPORTED_ARCH})
add_compiler_rt_runtime(clang_rt.crtbegin
OBJECT
ARCHS ${arch}
SOURCES ${CMAKE_CURRENT_SOURCE_DIR}/crtbegin.c
CFLAGS ${CRT_CFLAGS}
PARENT_TARGET crt)
add_compiler_rt_runtime(clang_rt.crtend
OBJECT
ARCHS ${arch}
SOURCES ${CMAKE_CURRENT_SOURCE_DIR}/crtend.c
CFLAGS ${CRT_CFLAGS}
PARENT_TARGET crt)
endforeach()
add_dependencies(compiler-rt crt)
endif()
Reference in New Issue Copy Permalink