maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages 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.

742 lines
17 KiB
CMake
Raw Normal View History

Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08: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-10 05:45:52 +08:00
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
[CMake] Bump CMake minimum version to 3.13.4 This upgrade should be friction-less because we've already been ensuring that CMake >= 3.13.4 is used. This is part of the effort discussed on llvm-dev here: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140578.html Differential Revision: https://reviews.llvm.org/D78648
2020-04-22 23:15:05 +08:00
cmake_minimum_required(VERSION 3.13.4)
[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-10 05:45:52 +08:00
[compiler-rt] Set CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY when building builtins standalone When building builtins, the toolchain might not yet be at a stage when linking a test application works yet, as builtins aren't available. Therefore set CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY, to avoid failing the compiler sanity check. Setting CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY has the risk of making checks for library availability succeed falsely (e.g. indicating that libs would be available that really aren't, as the tests don't do any linking), but the builtins library doesn't try to link against any external libraries (and only produces static libraries anyway), so it should be safe here. This avoids having to set CMAKE_C_COMPILER_WORKS when bootstrapping a cross toolchain, when building the builtins. Differential Revision: https://reviews.llvm.org/D91334
2020-11-12 17:09:38 +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-10 05:45:52 +08:00
project(CompilerRTBuiltins C ASM)
set(COMPILER_RT_STANDALONE_BUILD TRUE)
set(COMPILER_RT_BUILTINS_STANDALONE_BUILD TRUE)
list(INSERT CMAKE_MODULE_PATH 0
"${CMAKE_SOURCE_DIR}/../../cmake"
"${CMAKE_SOURCE_DIR}/../../cmake/Modules")
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 13:51:05 +08:00
load_llvm_config()
construct_compiler_rt_default_triple()
[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-10 05:45:52 +08: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-22 04:03:13 +08: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 10:38:15 +08: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-10 05:45:52 +08:00
include(AddCompilerRT)
[AIX][compiler-rt] Use the AR/ranlib mode flag for 32-bit and 64-bit mode since we will be building both 32-bit and 64-bit compiler-rt builtins from a single configuration. Reviewed By: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D87113
2020-01-02 23:11:59 +08:00
if(${CMAKE_SYSTEM_NAME} MATCHES "AIX")
set(CMAKE_C_ARCHIVE_CREATE "<CMAKE_AR> -X32_64 qc <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_CXX_ARCHIVE_CREATE "<CMAKE_AR> -X32_64 qc <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_C_ARCHIVE_APPEND "<CMAKE_AR> -X32_64 q <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_CXX_ARCHIVE_APPEND "<CMAKE_AR> -X32_64 q <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_C_ARCHIVE_FINISH "<CMAKE_RANLIB> -X32_64 <TARGET>")
set(CMAKE_CXX_ARCHIVE_FINISH "<CMAKE_RANLIB> -X32_64 <TARGET>")
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-10 05:45:52 +08: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-02-01 07: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-10 05:45:52 +08:00
include(builtin-config-ix)
[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-08 09: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-13 03:17:05 +08: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 17:20:33 +08: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 22:52:14 +08:00
bswapdi2.c
bswapsi2.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08: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-17 12:56:01 +08:00
divmodti4.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08: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-13 02:33:42 +08:00
extendhfsf2.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08: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-07 02:12:02 +08:00
ffssi2.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08: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 09:05:05 +08:00
fp_mode.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08: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-10 01:02:16 +08:00
os_version_check.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08: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-13 02:33:42 +08:00
truncdfhf2.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08: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-13 02:33:42 +08:00
truncsfhf2.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08: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-06 05:30:40 +08:00
umodti3.c
)
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08: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-17 06:10:22 +08:00
# TODO: Several "tf" files (and divtc3.c, but not multc3.c) are in
# GENERIC_SOURCES instead of here.
[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 21:34:17 +08: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-26 03:32:41 +08: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 21:34:17 +08: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-26 03:32:41 +08: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 21:34:17 +08: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 21:26:18 +08: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 21:34:17 +08: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-26 03:32:41 +08: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 21:34:17 +08: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 21:26:18 +08: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-06 05:30:40 +08: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 21:34:17 +08: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-02 05:05:49 +08: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-15 07:22:53 +08: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-02 05:05:49 +08:00
[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-13 03:33:30 +08:00
if(NOT FUCHSIA AND NOT COMPILER_RT_BAREMETAL_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 23:34:25 +08: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-06 05:30:40 +08: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-13 03:33:30 +08: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-06 05:30:40 +08: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 23:34:25 +08:00
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-02 05:05:49 +08: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 09:29:26 +08: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-06 05:30:40 +08: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 09:29:26 +08: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 23:28:44 +08: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-06 05:30:40 +08: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 23:28:44 +08: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 23:55:17 +08: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-06 05:30:40 +08: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 23:55:17 +08: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-13 03:33:30 +08: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-06 05:30:40 +08: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-13 03:33:30 +08: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-17 06:10:22 +08:00
# These files are used on 32-bit and 64-bit x86.
cmake list formatting fix
2020-07-17 06:29:48 +08:00
set(x86_ARCH_SOURCES
cpu_model.c
)
[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-17 06:10:22 +08: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-12-01 03:39:33 +08:00
divxc3.c
fixxfdi.c
fixxfti.c
fixunsxfdi.c
fixunsxfsi.c
fixunsxfti.c
floatdixf.c
floattixf.c
floatundixf.c
floatuntixf.c
mulxc3.c
powixf2.c
)
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 10:47:19 +08: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-18 00:23:05 +08: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-19 14:59:36 +08:00
${GENERIC_SOURCES}
[builtins] Build x86_64 with GENERIC_TF_SOURCES llvm-svn: 358706
2019-04-19 03:29:03 +08: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-19 14:59:36 +08: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-06 05:30:40 +08:00
x86_64/floatdidf.c
x86_64/floatdisf.c
x86_64/floatundidf.S
x86_64/floatundisf.S
)
[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-19 14:59:36 +08: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-17 06:10:22 +08:00
if (NOT ANDROID)
set(x86_64_SOURCES
${x86_64_SOURCES}
${x86_80_BIT_SOURCES}
x86_64/floatdixf.c
x86_64/floatundixf.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-19 14:59:36 +08: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 10:47:19 +08: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-18 00:23:05 +08: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 10:47:19 +08: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-06 05:30:40 +08:00
${x86_64_SOURCES}
x86_64/chkstk.S
x86_64/chkstk2.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 10:47:19 +08:00
endif()
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08: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-18 00:23:05 +08: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-19 14:59:36 +08: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-06 05:30:40 +08: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-18 00:23:05 +08: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-17 06:10:22 +08: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 10:47:19 +08: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-06 05:30:40 +08:00
${i386_SOURCES}
i386/chkstk.S
i386/chkstk2.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 10:47:19 +08: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 20:56:04 +08: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 10:47:19 +08: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-19 14:59:36 +08: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-06 05:30:40 +08: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-19 14:59:36 +08: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 10:47:19 +08: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 20:55:06 +08:00
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08:00
set(arm_SOURCES
Revert "Revert "[builtins] Rounding mode support for addxf3/subxf3"" Test failure fixed. This reverts commit e204d244badb2e9765a1020f41c773f63da208f4. llvm-svn: 371003
2019-09-05 09:05:05 +08: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-05 05:58:39 +08: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
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
arm/udivmodsi4.S
arm/udivsi3.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-06 05:30:40 +08:00
arm/umodsi3.S
[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-19 14:59:36 +08:00
${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-06 05:30:40 +08: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-05 05:58:39 +08:00
[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-20 02:46:11 +08:00
set(thumb1_SOURCES
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 14:04:10 +08: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-06 05:30:40 +08: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-20 02:46:11 +08: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-05 05:58:39 +08: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 08:25:37 +08: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 17:20:33 +08: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-07 05:34:02 +08: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-19 02:10:33 +08:00
arm/aeabi_drsub.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08: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-19 02:10:33 +08:00
arm/aeabi_frsub.c
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08: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-06 05:30:40 +08: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-20 02:46:11 +08: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-06 00:24:56 +08: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-06 05:30:40 +08: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-06 00:24:56 +08: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-06 05:30:40 +08: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 22:44:54 +08: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-05 05:58:39 +08:00
arm/adddf3vfp.S
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08: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 22:44:54 +08: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-06 05:30:40 +08: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-06 00:24:56 +08: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-06 05:30:40 +08:00
arm/sync_synchronize.S
)
Revert "[cmake] [ARM] Check if VFP is supported before including any VFP builtins" This reverts commit 2a10f5da5acb1b51d0a2ecf13dca0bf1de859db2. llvm-svn: 333232
2018-05-25 05:36:27 +08: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 22:44:54 +08: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-06 05:30:40 +08: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-05 05:58:39 +08:00
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-20 05:22:38 +08: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-06 05:30:40 +08:00
arm/aeabi_idivmod.S
arm/aeabi_ldivmod.S
arm/aeabi_uidivmod.S
arm/aeabi_uldivmod.S
arm/chkstk.S
mingw_fixfloat.c
[compiler-rt] Use arm-specific builtins sources for arm/mingw builds Previously, that configuration only used the generic sources, in addition to the couple specifically chosen arm/mingw files. Differential Revision: https://reviews.llvm.org/D98547
2021-03-12 04:17:48 +08:00
${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-06 05:30:40 +08: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-02 06:00:54 +08: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-06 00:24:56 +08: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-05 05:58:39 +08:00
set(arm_SOURCES
${arm_SOURCES}
${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-06 05:30:40 +08: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-20 02:46:11 +08:00
set(thumb1_SOURCES
${thumb1_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-06 05:30:40 +08: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-05 05:58:39 +08:00
endif()
Move original compiler-rt functions (libgcc replacement) to lib/builtins directory llvm-svn: 201393
2014-02-14 17:20:33 +08: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 21:43:37 +08: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 21:34:17 +08: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-06 05:30:40 +08:00
${GENERIC_SOURCES}
[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 23:02:57 +08:00
cpu_model.c
Revert "Revert "[builtins] Rounding mode support for addxf3/subxf3"" Test failure fixed. This reverts commit e204d244badb2e9765a1020f41c773f63da208f4. llvm-svn: 371003
2019-09-05 09:05:05 +08: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-06 05:30:40 +08: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 21:43:37 +08:00
[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 23:02:57 +08: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-06 04:45:22 +08: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 14:15:58 +08: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 23:02:57 +08: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 17:45:57 +08: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 23:02:57 +08:00
foreach(pat cas swp ldadd ldclr ldeor ldset)
foreach(size 1 2 4 8 16)
foreach(model 1 2 3 4)
if(pat STREQUAL "cas" OR NOT size STREQUAL "16")
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 14:15:58 +08:00
set(helper_asm "${OA_HELPERS_DIR}/outline_atomic_${pat}${size}_${model}.S")
[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 23:02:57 +08:00
add_custom_command(
OUTPUT ${helper_asm}
[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 17:45:57 +08:00
COMMAND ${CMAKE_COMMAND} -E ${COMPILER_RT_LINK_OR_COPY} "${CMAKE_CURRENT_SOURCE_DIR}/aarch64/lse.S" "${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 23:02:57 +08: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 14:15:58 +08: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 23:02:57 +08: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 14:15:58 +08: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 23:02:57 +08: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 14:52:52 +08: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-06 05:30:40 +08: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 14:52:52 +08:00
endif()
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 11:26:01 +08: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-09-01 05:24:50 +08:00
set(armv7_SOURCES ${arm_SOURCES})
set(armv7s_SOURCES ${arm_SOURCES})
[asan] Add iOS support. llvm-svn: 259451
2016-02-02 10:01:17 +08: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-09-01 05:24:50 +08: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-12 10:58:15 +08:00
set(arm64e_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-09-01 05:24:50 +08: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-30 07:13:45 +08: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-20 02:46:11 +08: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-30 07:13:45 +08:00
set(armv7m_SOURCES ${arm_SOURCES})
set(armv7em_SOURCES ${arm_SOURCES})
Add basic compiler-rt builtins support for hexagon. Differential Revision: https://reviews.llvm.org/D46364 llvm-svn: 331881
2018-05-09 22:44:54 +08: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-06 05:30:40 +08:00
hexagon/umodsi3.S
[Hexagon] Define __ELF__ by default. Differential Revision: https://reviews.llvm.org/D74972
2020-02-22 03:41:22 +08: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-06 05:30:40 +08:00
)
Add basic compiler-rt builtins support for hexagon. Differential Revision: https://reviews.llvm.org/D46364 llvm-svn: 331881
2018-05-09 22:44:54 +08: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 17:02:38 +08: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 21:34:17 +08: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 17:02:38 +08:00
[compiler-rt][AIX] Add CMake support for 32-bit Power builds This patch enables support for building compiler-rt builtins for 32-bit Power arch on AIX. For now, we leave out the specialized ppc builtin implementations for 128-bit long double and friends since those will need some special handling for AIX. Reviewed By: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D87383
2020-09-03 23:40:13 +08:00
set(powerpc_SOURCES ${GENERIC_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-12-01 05:04:11 +08:00
set(powerpc64_SOURCES
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-06 05:30:40 +08: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 23:30:17 +08:00
# These routines require __int128, which isn't supported on AIX.
if (NOT ${CMAKE_SYSTEM_NAME} MATCHES "AIX")
set(powerpc64_SOURCES
ppc/floattitf.c
ppc/fixtfti.c
ppc/fixunstfti.c
${powerpc64_SOURCES}
)
endif()
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-12-01 05:04:11 +08:00
set(powerpc64le_SOURCES ${powerpc64_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 15:47:27 +08:00
set(riscv_SOURCES ${GENERIC_SOURCES} ${GENERIC_TF_SOURCES})
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-06 05:30:40 +08: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 20:04:25 +08: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 15:47:27 +08: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 16:30:17 +08: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-08 03:03:11 +08: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-06 05:30:40 +08:00
${GENERIC_SOURCES}
)
[WebAssembly] Include GENERIC_TF_SOURCES in wasm builds Differential Revision: https://reviews.llvm.org/D39748 llvm-svn: 317601
2017-11-08 03:03:11 +08: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-06 05:30:40 +08:00
${GENERIC_SOURCES}
)
[WebAssembly] Enable the builtins library for WebAssembly. llvm-svn: 257619
2016-01-14 00:56:15 +08: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 15:39:39 +08: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 17:33:45 +08:00
add_custom_target(builtins)
[compiler-rt] Fix VisualStudio virtual folders layout Summary: This patch is a refactoring of the way cmake 'targets' are grouped. It won't affect non-UI cmake-generators. Clang/LLVM are using a structured way to group targets which ease navigation through Visual Studio UI. The Compiler-RT projects differ from the way Clang/LLVM are grouping targets. This patch doesn't contain behavior changes. Reviewers: kubabrecka, rnk Subscribers: wang0109, llvm-commits, kubabrecka, chrisha Differential Revision: http://reviews.llvm.org/D21952 llvm-svn: 275111
2016-07-12 05:51:56 +08:00
set_target_properties(builtins PROPERTIES FOLDER "Compiler-RT Misc")
[CMake] Add top-level target for each compiler-rt library, and add 'compiler-rt' target encompassing them all. llvm-svn: 201556
2014-02-18 17:33:45 +08:00
[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-09-01 05:24:50 +08: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-30 07:21:07 +08: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 23:18:17 +08: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 20:56:04 +08: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-23 04:33:47 +08:00
set(BUILTIN_CFLAGS "")
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-29 07:19:03 +08:00
[compiler-rt] [builtins] Use _Float16 on extendhfsf2, truncdfhf2 __truncsfhf2 if available On AArch64 it allows use the native FP16 ABI (although libcalls are not emitted for fptrunc/fpext lowering), while on other architectures the expected current semantic is preserved (arm for instance). For testing the _Float16 usage is enabled by architecture base, currently only for arm, aarch64, and arm64. This re-enabled revert done by https://reviews.llvm.org/rGb534beabeed3ba1777cd0ff9ce552d077e496726 Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D92241
2020-12-04 02:29:45 +08:00
append_list_if(COMPILER_RT_HAS_FLOAT16 -DCOMPILER_RT_HAS_FLOAT16 BUILTIN_CFLAGS)
builtins: switch to c11 from c99 This fixes an incorrect standard usage of GNU99 when the compiler check was for the ISO standard C99. Furthermore, bump the dependency up to C11. The motivation for this change is ARM EHABI compatibility with clang 3.8. We rely on a type definition redefinition which causes an error with -Werror builds. This is problematic for FreeBSD builds. Switching to C11 allows the compatibility without the unnecessary pedantic warning. The alternative would be to clutter the support header with a `pragma clang diagnostic ignore`. GCC 4.8+ and the supported clang revisions along with MSVC support enough of C11 to allow building the builtins in C11 mode. No functional change intended. llvm-svn: 288099
2016-11-29 10:31:40 +08:00
append_list_if(COMPILER_RT_HAS_STD_C11_FLAG -std=c11 BUILTIN_CFLAGS)
[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-23 04:33:47 +08: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-02-01 07: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-23 04:33:47 +08: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-08 09: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 09:59:35 +08: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-23 04:33:47 +08: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 11:37:12 +08:00
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-29 07:19:03 +08: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-08 09: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 09:59:35 +08: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-29 07:19:03 +08: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 14:15:58 +08: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-09-01 05:24:50 +08: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-27 07:44:22 +08:00
if (CAN_TARGET_${arch})
[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-31 02:18:59 +08:00
# For ARM archs, exclude any VFP builtins if VFP is not supported
if (${arch} MATCHES "^(arm|armhf|armv7|armv7s|armv7k|armv7m|armv7em)$")
string(REPLACE ";" " " _TARGET_${arch}_CFLAGS "${TARGET_${arch}_CFLAGS}")
[builtins][ARM] Check __ARM_FP instead of __VFP_FP__. This patch fixes builtins' CMakeLists.txt and their VFP tests to check the standard macro defined in the ACLE for VFP support. It also enables the tests to be built and run for single-precision-only targets while builtins were built with double-precision support. Differential revision: https://reviews.llvm.org/D92497
2020-12-05 12:53:23 +08:00
check_compile_definition(__ARM_FP "${CMAKE_C_FLAGS} ${_TARGET_${arch}_CFLAGS}" 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-31 02:18:59 +08: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 22:44:54 +08: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
check_c_source_compiles("#if !(__ARM_FP & 0x8)
#error No double-precision support!
#endif
int main() { return 0; }" COMPILER_RT_HAS_${arch}_VFP_DP)
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-31 02:18:59 +08:00
endif()
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-19 14:59:36 +08: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-27 07:44:22 +08: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 23:20:33 +08: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")
[Builtin] Unxfail tests for armhf Summary: Originally, a few tests fail for armhf target due to: 1) COMPILER_RT_ARMHF_TARGET was not set when building the lib 2) COMPILER_RT_ABI should not be defined as `__attribute__((pcs("aapcs")))` for armhf when building for both lib and tests This address https://bugs.llvm.org//show_bug.cgi?id=32261 mulsc3_test.c is a newly exposed issue, which will be addressed separately. Reviewers: rengolin, compnerd Reviewed By: compnerd Subscribers: aemerson, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D31448 llvm-svn: 298974
2017-03-29 11:36:46 +08:00
list(APPEND BUILTIN_CFLAGS -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 23:20:33 +08:00
endif()
[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-03-01 02:24:09 +08:00
# For RISCV32, we must force enable int128 for compiling long
# double routines.
if("${arch}" STREQUAL "riscv32")
list(APPEND BUILTIN_CFLAGS -fforce-enable-int128)
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-26 03:53:09 +08: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-09-01 05:24:50 +08:00
ARCHS ${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-27 07:44:22 +08: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-29 07:19:03 +08:00
DEFS ${BUILTIN_DEFS}
[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-23 04:33:47 +08:00
CFLAGS ${BUILTIN_CFLAGS}
[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-26 03:53:09 +08:00
PARENT_TARGET builtins)
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-27 07:44:22 +08: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 17:33:45 +08:00
add_dependencies(compiler-rt builtins)