| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[macOS] stop generating the libclang_rt.10.4.a library for macOS 10.4 The support for macOS 10.4 has been dropped by Xcode 10. rdar://42876880 llvm-svn: 339277 | 7 年前 | |
[compiler-rt][AArch64] Don't use x18 in __arm_sme_save (#157802) The AAPCS recommends avoiding the use of x18 as it may be used for other purposes such as a shadow call stack. In this particular case it could just as well use x16 instead. | 10 个月前 | |
[compiler-rt][ARM] Optimized mulsf3 and divsf3 (#168394) (Reland of #161546, fixing three build and test issues) This commit adds optimized assembly versions of single-precision float multiplication and division. Both functions are implemented in a style that can be assembled as either of Arm and Thumb2; for multiplication, a separate implementation is provided for Thumb1. Also, extensive new tests are added for multiplication and division. These implementations can be removed from the build by defining the cmake variable COMPILER_RT_ARM_OPTIMIZED_FP=OFF. Outlying parts of the functionality which are not on the fast path, such as NaN handling and underflow, are handled in helper functions written in C. These can be shared between the Arm/Thumb2 and Thumb1 implementations, and also reused by other optimized assembly functions we hope to add in future. | 8 个月前 | |
[compiler-rt][builtins] Fix wrong ABI of AVR __mulqi3 & __mulhi3 Reviewed By: aykevl, dylanmckay Differential Revision: https://reviews.llvm.org/D125077 | 4 年前 | |
[X86] Remove vector length (256 vs 512) distinction of AVX10 (#167736) As in title. AVX10.x doesn't distinguish between available vector lengths. -mattr=avx10.x-512 and defining of macros with _512 is kept for compatibility. Bit-positions of avx10.1/2 features in compiler-rt and X86TargetParser are synced to match those in the gcc. | 8 个月前 | |
[compiler-rt][Hexagon] Remove fma/fmin/max code This code should reside in the c-library. Differential Revision: https://reviews.llvm.org/D82263 | 5 年前 | |
Revert "[compiler-rt] [builtins] Remove unused/misnamed x86 chkstk functions" This reverts parts of commit 885d7b759b5c166c07c07f4c58c6e0ba110fb0c2, and adds verbose comments explaining all the variants of this function, for clarity for future readers. It turns out that those functions actually weren't misnamed or unused after all: Apparently Clang doesn't match GCC when it comes to what stack probe function is referenced on i386 mingw. GCC < 4.6 references a symbol named "___chkstk", with three leading underscores, and GCC >= 4.6 references "___chkstk_ms". Restore these functions, to allow linking object files built with GCC with compiler-rt. | 8 个月前 | |
[compiler-rt] Fix build errors when using gcc on LoongArch - GCC does not recognize $fcsr0, uses $r0 instead. - GCC does not implement __builtin_thread_pointer, which can be obtained directly through $tp. Reviewed By: SixWeining Differential Revision: https://reviews.llvm.org/D140545 | 3 年前 | |
Revert "Add extendhfxf2 into compiler rt (#111099)" This reverts commit 5f7bad07b9d5b6c5cfa8c16a4e62cf1e128725be. These tests fail to build in multiple configurations, see https://github.com/llvm/llvm-project/pull/111099. | 1 年前 | |
[builtins] Revert accidental change to PPC implementation in 05a4212cc76d This commit was supposed to only change the generic implementation. Should fix the build bot errors. | 2 年前 | |
[compiler-rt][RISC-V] ILP32E/LP64E Save/Restore Grouping (#95398) This changes the save/restore procedures to save/restore registers one by one - to match the stack alignment for the ILP32E/LP64E ABIs, rather than the larger batches of the conventional ABIs. The implementations of the save routines are not tail-shared, to reduce the number of instructions. I think this also helps code size but I need to check this again. I would expect (but haven't measured) that the majority of functions compiled for the ILP32E/LP64E ABIs will in fact use both callee-saved registers, and therefore there are still savings to be had, but I think those can come later, with more data (especially if those changes are just to the instruction sequences we use to save the registers, rather than the number and alignment of how this is done). This is a potential break for all of the ILP32E/LP64E ABI - we may instead have to teach the compiler to emit the CFI information correctly for the grouping we already have implemented (because that grouping matches GCC). It depends on how intentional we think the grouping is in the original ILP32E/LP64E save/restore implementation was, and whether we think we can fix that now. | 1 年前 | |
[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 | 6 年前 | |
[WebAssembly] Define llvm-internal WasmEH tags in compiler-rt (#160959) The __c_longjmp and __cpp_exceptions tags are used internally by llvm to implement setjmp/longjmp and C++ exception handling respectively. These symbols were previously defined weakly in each object file but were recently converted to external references in #159143. They now need to be defined somewhere in the runtime libraries. I think compiler-rt is likely the most sensible place for them. | 9 个月前 | |
[compiler-rt] Remove duplicate MS names for chkstk symbols (#80450) Prior to 885d7b759b5c166c07c07f4c58c6e0ba110fb0c2, the builtins library contained two chkstk implementations for each of i386 and x86_64, one that was used in mingw environments, and one unused (with a symbol name not matching anything that is used anywhere). Some of the functions additionally had other, also unused, aliases. After cleaning this up in 885d7b759b5c166c07c07f4c58c6e0ba110fb0c2, the unused symbol names were removed. At the same time, symbol aliases were added for the names as they are used by MSVC; the functions are functionally equivalent, but have different names between mingw and MSVC style environments. By adding a symbol alias (so that one object file contains two different symbols for the same function), users can run into problems with duplicate definitions, if they themselves define one of the symbols (for various reasons), but need to link in the other one. This happens for Wine, which provides their own definition of "__chkstk", but when built in mingw mode does need compiler-rt to provide the mingw specific symbol names; see https://github.com/mstorsjo/llvm-mingw/issues/397. To avoid the issue, remove the extra MS style names. They weren't entirely usable as such for MSVC style environments anyway, as compiler-rt builtins don't build these object files at all, when built in MSVC mode; thus, the effort to provide them for MSVC style environments in 885d7b759b5c166c07c07f4c58c6e0ba110fb0c2 was a half-hearted step towards that. If we really do want to provide those functions (as an alternative to the ones provided by MSVC itself), we should do it in a separate object file (even if the function implementation is the same), so that users who have a definition of one of them but need a definition of the other, won't have conflicts. Additionally, if we do want to provide them for MSVC, those files actually should be built when building the builtins in MSVC mode as well (see compiler-rt/lib/builtins/CMakeLists.txt). If we do that, there's a risk that an MSVC style build ends up linking in and preferring our implementation over the one provided by MSVC, which would be suboptimal. Our implementation always probes the requested amount of stack, while the MSVC one checks the amount of allocated stack and only probes as much as really is needed. In short - this reverts the situation to what it was in the 17.x release series (except for unused functions that have been removed). | 2 年前 | |
[M68k][compiler-rt] Allow compiler-rt builtins to be built for M68k (#169256) I've tested this locally, and the builtins build proceeds without a hitch for m68k-none-none. This is part of a larger effort to establish a working m68k baremetal toolchain. | 8 个月前 | |
[AArch64] fix trampoline implementation: use X15 (#126743) AAPCS64 reserves any of X9-X15 for a compiler to choose to use for this purpose, and says not to use X16 or X18 like GCC (and the previous implementation) chose to use. The X18 register may need to get used by the kernel in some circumstances, as specified by the platform ABI, so it is generally an unwise choice. Simply choosing a different register fixes the problem of this being broken on any platform that actually follows the platform ABI (which is all of them except EABI, if I am reading this linux kernel bug correctly https://lkml2.uits.iu.edu/hypermail/linux/kernel/2001.2/01502.html). As a side benefit, also generate slightly better code and avoids needing the compiler-rt to be present. I did that by following the XCore implementation instead of PPC (although in hindsight, following the RISCV might have been slightly more readable). That X18 is wrong to use for this purpose has been known for many years (e.g. https://www.mail-archive.com/gcc@gcc.gnu.org/msg76934.html) and also known that fixing this to use one of the correct registers is not an ABI break, since this only appears inside of a translation unit. Some of the other temporary registers (e.g. X9) are already reserved inside llvm for internal use as a generic temporary register in the prologue before saving registers, while X15 was already used in rare cases as a scratch register in the prologue as well, so I felt that seemed the most logical choice to choose here. | 1 年前 | |
[compiler-rt] Fix signed shift overflows in absvdi2.c, absvsi2.c, negvdi2.c and negvsi2.c When compiling compiler-rt with -fsanitize=undefined and running testcases you end up with the following warnings: UBSan: absvdi2.c:21:23: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') UBSan: absvsi2.c:21:23: left shift of 1 by 31 places cannot be represented in type 'si_int' (aka 'long') UBSan: negvdi2.c:20:32: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') UBSan: negvsi2.c:20:32: left shift of 1 by 31 places cannot be represented in type 'si_int' (aka 'long') This can be avoided by doing the shift in a matching unsigned variant of the type. This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D146932 | 3 年前 | |
[compiler-rt] Fix signed shift overflows in absvdi2.c, absvsi2.c, negvdi2.c and negvsi2.c When compiling compiler-rt with -fsanitize=undefined and running testcases you end up with the following warnings: UBSan: absvdi2.c:21:23: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') UBSan: absvsi2.c:21:23: left shift of 1 by 31 places cannot be represented in type 'si_int' (aka 'long') UBSan: negvdi2.c:20:32: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') UBSan: negvsi2.c:20:32: left shift of 1 by 31 places cannot be represented in type 'si_int' (aka 'long') This can be avoided by doing the shift in a matching unsigned variant of the type. This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D146932 | 3 年前 | |
[builtins] Fix signed shift overflows in absvti2.c and negvti2.c When compiling the builtins with the undefined behavior sanitizer and running testcases you end up with the following warning: UBSan: negvti2.c:22:32: left shift of 1 by 127 places cannot be represented in type 'ti_int' (aka '__int128') UBSan: absvti2.c:23:23: left shift of 1 by 127 places cannot be represented in type 'ti_int' (aka '__int128') This can be avoided by doing the shift in a matching unsigned variant of the type. This is the same kind of fixes that already was done in commit 854686f0794b9d0695d5a0a85ea1e7e71ba8edfd This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D158816 | 2 年前 | |
Revert "Revert "[builtins] Rounding mode support for addxf3/subxf3"" Test failure fixed. This reverts commit e204d244badb2e9765a1020f41c773f63da208f4. llvm-svn: 371003 | 6 年前 | |
Revert "Revert "[builtins] Rounding mode support for addxf3/subxf3"" Test failure fixed. This reverts commit e204d244badb2e9765a1020f41c773f63da208f4. llvm-svn: 371003 | 6 年前 | |
[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC Currently the *tf builtin functions can only be built if long double is an IEEE float, which prevents them from being available e.g. for x86 targets (unlike libgcc which has them). This non-functional change prepares the builtins library *tf functions for being able to target x86 by decoupling their presence from CRT_LDBL_128BIT and instead checking for a CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is currently only set if long double is an IEEE 128-bit float. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D153812 | 2 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Canonicalize PowerPC detection macros to __powerpc__ The lowercase __ppc__ is not defined by Linux GCC, therefore it lures users to write code which is not portable to GCC. Migrate to __powerpc__ in preparation for undefining __ppc__. __powerpc__ is much more common than __PPC__. | 3 年前 | |
[builtins] Fix signed shift overflows in ashlti3.c, ashrti3.c, ashldi3.c and ashrdi3.c When compiling the builtins with the undefined behavior sanitizer and running testcases you end up with the following warning: UBSan: ashlti3.c:33:35: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') UBSan: ashrti3.c:34:34: left shift of negative value -81985529216486891 This can be avoided by doing the shift in a matching unsigned variant of the type. The same kind of patterns are found in ashldi3.c and ashrdi3.c This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D158819 | 2 年前 | |
[builtins] Fix signed shift overflows in ashlti3.c, ashrti3.c, ashldi3.c and ashrdi3.c When compiling the builtins with the undefined behavior sanitizer and running testcases you end up with the following warning: UBSan: ashlti3.c:33:35: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') UBSan: ashrti3.c:34:34: left shift of negative value -81985529216486891 This can be avoided by doing the shift in a matching unsigned variant of the type. The same kind of patterns are found in ashldi3.c and ashrdi3.c This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D158819 | 2 年前 | |
[builtins] Fix signed shift overflows in ashlti3.c, ashrti3.c, ashldi3.c and ashrdi3.c When compiling the builtins with the undefined behavior sanitizer and running testcases you end up with the following warning: UBSan: ashlti3.c:33:35: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') UBSan: ashrti3.c:34:34: left shift of negative value -81985529216486891 This can be avoided by doing the shift in a matching unsigned variant of the type. The same kind of patterns are found in ashldi3.c and ashrdi3.c This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D158819 | 2 年前 | |
[builtins] Fix signed shift overflows in ashlti3.c, ashrti3.c, ashldi3.c and ashrdi3.c When compiling the builtins with the undefined behavior sanitizer and running testcases you end up with the following warning: UBSan: ashlti3.c:33:35: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') UBSan: ashrti3.c:34:34: left shift of negative value -81985529216486891 This can be avoided by doing the shift in a matching unsigned variant of the type. The same kind of patterns are found in ashldi3.c and ashrdi3.c This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D158819 | 2 年前 | |
[compiler-rt] Add CMake option to enable execute-only code generation on AArch64 (#140555) For a full toolchain supporting execute-only code generation the runtime libraries also need to be pre-compiled with it enabled. The generic RUNTIMES_EXECUTE_ONLY_CODE CMake option can now be used during build configuration to enable execute-only code generation in compiler-rt. The build option can only be enabled for a runtimes build of compiler-rt, because a recent version of Clang is needed to correctly compile assembly files with execute-only code support. Related RFC: https://discourse.llvm.org/t/rfc-execute-only-code-support-for-runtime-libraries-on-aarch64/86180 | 8 个月前 | |
[compiler-rt][builtins] Add opt-in pthread_mutex_t locks to libatomic (#95326) When an uninstrumented libatomic is used with a TSan instrumented memcpy, TSan may report a data race in circumstances where writes are arguably safe. This occurs because __atomic_compare_exchange won't be instrumented in an uninstrumented libatomic, so TSan doesn't know that the subsequent memcpy is race-free. On the other hand, pthread_mutex_(un)lock will be intercepted by TSan, meaning an uninstrumented libatomic will not report this false-positive. pthread_mutexes also may try a number of different strategies to acquire the lock, which may bound the amount of time a thread has to wait for a lock during contention. While pthread_mutex_lock has a larger overhead (due to the function call and some dispatching), a dispatch to libatomic already predicates a lack of performance guarantees. | 2 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[compiler-rt] Add initial ARM64EC builtins support (#139279) Use the aarch64 variants of assembly functions. Co-authored-by: Billy Laws <blaws05@gmail.com> | 1 年前 | |
[compiler-rt] Make sure __clzdi2 doesn't call itself recursively on sparc64 (#136737) On 64-bit platforms, libgcc doesn't ship with __clzsi2, so __builtin_clz gets lowered to __clzdi2. A check already exists for GCC, but as of commit 8210ca019839fc5430b3a95d7caf5c829df3232a clang also lowers __builtin_clz to __clzdi2 on sparc64. Update the check so that building __clzdi2 with clang/sparc64 also works. | 1 年前 | |
[builtins] Change si_int to int in some helper declarations This patch changes types of some integer function arguments or return values from si_int to the default int type to make it more compatible with libgcc. The compiler-rt/lib/builtins/README.txt has a link to the [libgcc specification](http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc). This specification has an explicit note on int, float and other such types being just illustrations in some cases while the actual types are expressed with machine modes. Such usage of always-32-bit-wide integer type may lead to issues on 16-bit platforms such as MSP430. Provided [libgcc2.h](https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/libgcc2.h;hb=HEAD) can be used as a reference for all targets supported by the libgcc, this patch fixes some existing differences in helper declarations. This patch is expected to not change behavior at all for targets with 32-bit int type. Differential Revision: https://reviews.llvm.org/D81285 | 5 年前 | |
[builtins] Change si_int to int in some helper declarations This patch changes types of some integer function arguments or return values from si_int to the default int type to make it more compatible with libgcc. The compiler-rt/lib/builtins/README.txt has a link to the [libgcc specification](http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc). This specification has an explicit note on int, float and other such types being just illustrations in some cases while the actual types are expressed with machine modes. Such usage of always-32-bit-wide integer type may lead to issues on 16-bit platforms such as MSP430. Provided [libgcc2.h](https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/libgcc2.h;hb=HEAD) can be used as a reference for all targets supported by the libgcc, this patch fixes some existing differences in helper declarations. This patch is expected to not change behavior at all for targets with 32-bit int type. Differential Revision: https://reviews.llvm.org/D81285 | 5 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Fix ABI-incompatibility with GCC for floating-point compare While implementing support for the float128 routines on x86_64, I noticed that __builtin_isinf() was returning true for 128-bit floating point values that are not infinite when compiling with GCC and using the compiler-rt implementation of the soft-float comparison functions. After stepping through the assembly, I discovered that this was caused by GCC assuming a sign-extended 64-bit -1 result, but our implementation returns an enum (which then has zeroes in the upper bits) and therefore causes the comparison with -1 to fail. Fix this by using a CMP_RESULT typedef and add a static_assert that it matches the GCC soft-float comparison return type when compiling with GCC (GCC has a __libgcc_cmp_return__ mode that can be used for this purpose). Also move the 3 copies of the same code to a shared .inc file. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D98205 | 5 年前 | |
[builtins] Fix ABI-incompatibility with GCC for floating-point compare While implementing support for the float128 routines on x86_64, I noticed that __builtin_isinf() was returning true for 128-bit floating point values that are not infinite when compiling with GCC and using the compiler-rt implementation of the soft-float comparison functions. After stepping through the assembly, I discovered that this was caused by GCC assuming a sign-extended 64-bit -1 result, but our implementation returns an enum (which then has zeroes in the upper bits) and therefore causes the comparison with -1 to fail. Fix this by using a CMP_RESULT typedef and add a static_assert that it matches the GCC soft-float comparison return type when compiling with GCC (GCC has a __libgcc_cmp_return__ mode that can be used for this purpose). Also move the 3 copies of the same code to a shared .inc file. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D98205 | 5 年前 | |
[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC Currently the *tf builtin functions can only be built if long double is an IEEE float, which prevents them from being available e.g. for x86 targets (unlike libgcc which has them). This non-functional change prepares the builtins library *tf functions for being able to target x86 by decoupling their presence from CRT_LDBL_128BIT and instead checking for a CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is currently only set if long double is an IEEE 128-bit float. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D153812 | 2 年前 | |
[compiler-rt] Make __EH_FRAME_LIST__ const to avoid RW .eh_frame mapping (#155764) (#155955) In crtbegin.c, __EH_FRAME_LIST__ was previously declared as a writable array of pointers. This caused the linker to place .eh_frame into a segment with read-write permissions, leading to larger virtual memory footprint at runtime (e.g. .eh_frame mapped into both LOAD and RELRO). Changing it to static void * const __EH_FRAME_LIST__[] ensures that the section is treated as read-only, matching GCC’s behavior with __EH_FRAME_BEGIN__. This prevents unnecessary RW mappings of .eh_frame while preserving the intended semantics. Fixes: #155764 | 11 个月前 | |
[compiler-rt] Move crt into builtins On Linux crt is typically use in combination with builtins. In the Clang driver the use of builtins and crt is controlled by the --rtlib option. Both builtins and crt also have similar build requirements where they need to be built before any other runtimes and must avoid dependencies. We also want builtins and crt these to be buildable separately from the rest of compiler-rt for bootstrapping purposes. Given how simple crt is, rather than maintaining a separate directory with its own separate build setup, it's more efficient to just move crt into builtins. We still use separate CMake option to control whether to built crt same as before. This is an alternative to D89492 and D136664. Differential Revision: https://reviews.llvm.org/D153989 | 3 年前 | |
[builtins] Change si_int to int in some helper declarations This patch changes types of some integer function arguments or return values from si_int to the default int type to make it more compatible with libgcc. The compiler-rt/lib/builtins/README.txt has a link to the [libgcc specification](http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc). This specification has an explicit note on int, float and other such types being just illustrations in some cases while the actual types are expressed with machine modes. Such usage of always-32-bit-wide integer type may lead to issues on 16-bit platforms such as MSP430. Provided [libgcc2.h](https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/libgcc2.h;hb=HEAD) can be used as a reference for all targets supported by the libgcc, this patch fixes some existing differences in helper declarations. This patch is expected to not change behavior at all for targets with 32-bit int type. Differential Revision: https://reviews.llvm.org/D81285 | 5 年前 | |
[builtins] Change si_int to int in some helper declarations This patch changes types of some integer function arguments or return values from si_int to the default int type to make it more compatible with libgcc. The compiler-rt/lib/builtins/README.txt has a link to the [libgcc specification](http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc). This specification has an explicit note on int, float and other such types being just illustrations in some cases while the actual types are expressed with machine modes. Such usage of always-32-bit-wide integer type may lead to issues on 16-bit platforms such as MSP430. Provided [libgcc2.h](https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/libgcc2.h;hb=HEAD) can be used as a reference for all targets supported by the libgcc, this patch fixes some existing differences in helper declarations. This patch is expected to not change behavior at all for targets with 32-bit int type. Differential Revision: https://reviews.llvm.org/D81285 | 5 年前 | |
[builtins] Change si_int to int in some helper declarations This patch changes types of some integer function arguments or return values from si_int to the default int type to make it more compatible with libgcc. The compiler-rt/lib/builtins/README.txt has a link to the [libgcc specification](http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc). This specification has an explicit note on int, float and other such types being just illustrations in some cases while the actual types are expressed with machine modes. Such usage of always-32-bit-wide integer type may lead to issues on 16-bit platforms such as MSP430. Provided [libgcc2.h](https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/libgcc2.h;hb=HEAD) can be used as a reference for all targets supported by the libgcc, this patch fixes some existing differences in helper declarations. This patch is expected to not change behavior at all for targets with 32-bit int type. Differential Revision: https://reviews.llvm.org/D81285 | 5 年前 | |
Reland "[builtins] Define fmax and scalbn inline" This reverts commit 680f836c2fa72166badd594a52b3f41b2ad074d2. Disable the non-default-rounding-mode scalbn[f] tests when we're using the MSVC libraries. Differential Revision: https://reviews.llvm.org/D91841 | 5 年前 | |
[builtins] Unify the softfloat division implementation This patch replaces three different pre-existing implementations of __div[sdt]f3 LibCalls with a generic one - like it is already done for many other LibCalls. Reviewed By: sepavloff Differential Revision: https://reviews.llvm.org/D85031 | 5 年前 | |
[NFC][compiler-rt] Factor out __div[sdt]i3 and __mod[dt]i3 implementations Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D86400 | 5 年前 | |
[builtins] Fix signed integer overflows in divmodsi4.c, divmoddi4.c and divmodti4.c When compiling the builtins with the undefined behavior sanitizer and running testcases you end up with the following warning: UBSan: divmodsi4.c:22:17: signed integer overflow: 2147483647 - -1 cannot be represented in type 'si_int' (aka 'long') This can be avoided by doing the subtract in a matching unsigned variant of the type. The same kind of pattern is found in divmoddi4.c and divmodti4.c This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D158821 | 2 年前 | |
[builtins] Fix signed integer overflows in divmodsi4.c, divmoddi4.c and divmodti4.c When compiling the builtins with the undefined behavior sanitizer and running testcases you end up with the following warning: UBSan: divmodsi4.c:22:17: signed integer overflow: 2147483647 - -1 cannot be represented in type 'si_int' (aka 'long') This can be avoided by doing the subtract in a matching unsigned variant of the type. The same kind of pattern is found in divmoddi4.c and divmodti4.c This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D158821 | 2 年前 | |
[builtins] Fix signed integer overflows in divmodsi4.c, divmoddi4.c and divmodti4.c When compiling the builtins with the undefined behavior sanitizer and running testcases you end up with the following warning: UBSan: divmodsi4.c:22:17: signed integer overflow: 2147483647 - -1 cannot be represented in type 'si_int' (aka 'long') This can be avoided by doing the subtract in a matching unsigned variant of the type. The same kind of pattern is found in divmoddi4.c and divmodti4.c This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D158821 | 2 年前 | |
[compiler-rt][builtins]Adjust complex division for aarch64 (#106664) Adjust __divsc3 to ensure consistent behavior across x86_64 and AArch64 when the divisor should be treated as infinity if one of its components is a NaN (including signaling NaNs). Test plan: ninja check-all | 1 年前 | |
[builtins] Unify the softfloat division implementation This patch replaces three different pre-existing implementations of __div[sdt]f3 LibCalls with a generic one - like it is already done for many other LibCalls. Reviewed By: sepavloff Differential Revision: https://reviews.llvm.org/D85031 | 5 年前 | |
[NFC][compiler-rt] Factor out __div[sdt]i3 and __mod[dt]i3 implementations Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D86400 | 5 年前 | |
[builtins] Fix divtc3.c etc. compilation on Solaris/SPARC with gcc (#101662) compiler-rt/lib/builtins/divtc3.c and multc3.c don't compile on Solaris/sparcv9 with gcc -m32: FAILED: projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.builtins-sparc.dir/divtc3.c.o [...] compiler-rt/lib/builtins/divtc3.c: In function ‘__divtc3’: compiler-rt/lib/builtins/divtc3.c:22:18: error: implicit declaration of function ‘__compiler_rt_logbtf’ [-Wimplicit-function-declaration] 22 | fp_t __logbw = __compiler_rt_logbtf( | ^~~~~~~~~~~~~~~~~~~~ and many more. It turns out that while the definition of __divtc3 is guarded with CRT_HAS_F128, the __compiler_rt_logbtf and other declarations use CRT_HAS_128BIT && CRT_HAS_F128 as guard. This only shows up with gcc since, as documented in Issue #41838, clang violates the SPARC psABI in not using 128-bit long double, so this code path isn't used. Fixed by changing the guards to match. Tested on sparcv9-sun-solaris2.11. | 1 年前 | |
[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC Currently the *tf builtin functions can only be built if long double is an IEEE float, which prevents them from being available e.g. for x86 targets (unlike libgcc which has them). This non-functional change prepares the builtins library *tf functions for being able to target x86 by decoupling their presence from CRT_LDBL_128BIT and instead checking for a CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is currently only set if long double is an IEEE 128-bit float. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D153812 | 2 年前 | |
[NFC][compiler-rt] Factor out __div[sdt]i3 and __mod[dt]i3 implementations Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D86400 | 5 年前 | |
[builtins] Avoid using long double in generic sources (#69754) Use of long double can be error-prone since it could be one of 80-bit extended precision float, IEEE 128-bit float, or IBM 128-bit float. Instead use an explicit xf_float typedef for the remaining cases where long double is being used in the implementation. This patch does not touch the PPC specializations which still use long double. | 2 年前 | |
Add some prototypes to these functions; NFC This is expected to fix the issues in this build bot: https://lab.llvm.org/buildbot/#/builders/37/builds/12312 | 4 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[compiler-rt][builtins] Add compiler flags to catch potential errors that can lead to security vulnerabilities Also, fix a few places that were causing -Wshadow and -Wformat-nonliteral warnings to be emitted. This reapplies the patch that was reverted in caaafe4ae250 because it broke Fuchsia builders. I reverted the changes I made to InstrProfData.inc and instead renamed the variables in InstrProfilingWriter.c. Also fixed a bug in function add_security_warnings that was causing it to pass -Wformat-nonliteral when the compiler doesn't support it. | 3 年前 | |
[SelectionDAG] Add STRICT_BF16_TO_FP and STRICT_FP_TO_BF16 (#80056) This patch adds the support for STRICT_BF16_TO_FP and STRICT_FP_TO_BF16. | 2 年前 | |
[builtins] Support building the 128-bit float functions on ld80 platforms (#68132) GCC provides these functions (e.g. __addtf3, etc.) in libgcc on x86_64. Since Clang supports float128, we can also enable the existing code by using float128 for fp_t if either __FLOAT128__ or __SIZEOF_FLOAT128__ is defined instead of only supporting these builtins for platforms with 128-bit IEEE long doubles. This commit defines a new tf_float typedef that matches a float with attribute((mode(TF)) on each given architecture. There are more tests that could be enabled for x86, but to keep the diff smaller, I restricted test changes to ones that started failing as part of this refactoring. This change has been tested on x86 (natively) and aarch64,powerpc64,riscv64 and sparc64 via qemu-user. This supersedes https://reviews.llvm.org/D98261 and should also cover the changes from https://github.com/llvm/llvm-project/pull/68041. | 2 年前 | |
[SystemZ] Add support for 16-bit floating point. (#109164) - _Float16 is now accepted by Clang. - The half IR type is fully handled by the backend. - These values are passed in FP registers and converted to/from float around each operation. - Compiler-rt conversion functions are now built for s390x including the missing extendhfdf2 which was added. Fixes #50374 | 1 年前 | |
[builtins][AArch32] Fix __gnu_* functions (#137638) Move to a consistent calling convention for both Clang/GNU such that they can be linked with each other. All ARM targets now use the soft-float calling convention for __gnu_h2f_ieee and __gnu_f2h_ieee, as described in https://github.com/ARM-software/abi-aa/blob/main/rtabi32/rtabi32.rst#the-floating-point-helper-functions. | 1 年前 | |
[builtins] Support building the 128-bit float functions on ld80 platforms (#68132) GCC provides these functions (e.g. __addtf3, etc.) in libgcc on x86_64. Since Clang supports float128, we can also enable the existing code by using float128 for fp_t if either __FLOAT128__ or __SIZEOF_FLOAT128__ is defined instead of only supporting these builtins for platforms with 128-bit IEEE long doubles. This commit defines a new tf_float typedef that matches a float with attribute((mode(TF)) on each given architecture. There are more tests that could be enabled for x86, but to keep the diff smaller, I restricted test changes to ones that started failing as part of this refactoring. This change has been tested on x86 (natively) and aarch64,powerpc64,riscv64 and sparc64 via qemu-user. This supersedes https://reviews.llvm.org/D98261 and should also cover the changes from https://github.com/llvm/llvm-project/pull/68041. | 2 年前 | |
| 1 年前 | ||
[builtins] Use aliases for function redirects Symbol aliases are supported by all platforms that compiler-rt builtins target, and we can use these instead of function redirects to avoid the extra indirection. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60931 llvm-svn: 359413 | 7 年前 | |
[builtins] Support building the 128-bit float functions on ld80 platforms (#68132) GCC provides these functions (e.g. __addtf3, etc.) in libgcc on x86_64. Since Clang supports float128, we can also enable the existing code by using float128 for fp_t if either __FLOAT128__ or __SIZEOF_FLOAT128__ is defined instead of only supporting these builtins for platforms with 128-bit IEEE long doubles. This commit defines a new tf_float typedef that matches a float with attribute((mode(TF)) on each given architecture. There are more tests that could be enabled for x86, but to keep the diff smaller, I restricted test changes to ones that started failing as part of this refactoring. This change has been tested on x86 (natively) and aarch64,powerpc64,riscv64 and sparc64 via qemu-user. This supersedes https://reviews.llvm.org/D98261 and should also cover the changes from https://github.com/llvm/llvm-project/pull/68041. | 2 年前 | |
[builtins] Avoid using long double in generic sources (#69754) Use of long double can be error-prone since it could be one of 80-bit extended precision float, IEEE 128-bit float, or IBM 128-bit float. Instead use an explicit xf_float typedef for the remaining cases where long double is being used in the implementation. This patch does not touch the PPC specializations which still use long double. | 2 年前 | |
[builtins] Support architectures with 16-bit int This is the first patch in a series to add support for the AVR target. This patch includes changes to make compiler-rt more target independent by not relying on the width of an int or long. Differential Revision: https://reviews.llvm.org/D78662 | 6 年前 | |
[builtins] Support architectures with 16-bit int This is the first patch in a series to add support for the AVR target. This patch includes changes to make compiler-rt more target independent by not relying on the width of an int or long. Differential Revision: https://reviews.llvm.org/D78662 | 6 年前 | |
[builtins] Change si_int to int in some helper declarations This patch changes types of some integer function arguments or return values from si_int to the default int type to make it more compatible with libgcc. The compiler-rt/lib/builtins/README.txt has a link to the [libgcc specification](http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc). This specification has an explicit note on int, float and other such types being just illustrations in some cases while the actual types are expressed with machine modes. Such usage of always-32-bit-wide integer type may lead to issues on 16-bit platforms such as MSP430. Provided [libgcc2.h](https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/libgcc2.h;hb=HEAD) can be used as a reference for all targets supported by the libgcc, this patch fixes some existing differences in helper declarations. This patch is expected to not change behavior at all for targets with 32-bit int type. Differential Revision: https://reviews.llvm.org/D81285 | 5 年前 | |
[builtins] Move Windows/ARM frontends for fix/float functions into the individual source files This avoids pulling in all of them if only one of them is needed (if builtins are built without -ffunction-sections), and matches how the similar aliases for AEABI are set up. Differential Revision: https://reviews.llvm.org/D107815 | 4 年前 | |
[builtins] Use aliases for function redirects Symbol aliases are supported by all platforms that compiler-rt builtins target, and we can use these instead of function redirects to avoid the extra indirection. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60931 llvm-svn: 359413 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Move Windows/ARM frontends for fix/float functions into the individual source files This avoids pulling in all of them if only one of them is needed (if builtins are built without -ffunction-sections), and matches how the similar aliases for AEABI are set up. Differential Revision: https://reviews.llvm.org/D107815 | 4 年前 | |
[builtins] Use aliases for function redirects Symbol aliases are supported by all platforms that compiler-rt builtins target, and we can use these instead of function redirects to avoid the extra indirection. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60931 llvm-svn: 359413 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC Currently the *tf builtin functions can only be built if long double is an IEEE float, which prevents them from being available e.g. for x86 targets (unlike libgcc which has them). This non-functional change prepares the builtins library *tf functions for being able to target x86 by decoupling their presence from CRT_LDBL_128BIT and instead checking for a CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is currently only set if long double is an IEEE 128-bit float. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D153812 | 2 年前 | |
[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC Currently the *tf builtin functions can only be built if long double is an IEEE float, which prevents them from being available e.g. for x86 targets (unlike libgcc which has them). This non-functional change prepares the builtins library *tf functions for being able to target x86 by decoupling their presence from CRT_LDBL_128BIT and instead checking for a CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is currently only set if long double is an IEEE 128-bit float. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D153812 | 2 年前 | |
[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC Currently the *tf builtin functions can only be built if long double is an IEEE float, which prevents them from being available e.g. for x86 targets (unlike libgcc which has them). This non-functional change prepares the builtins library *tf functions for being able to target x86 by decoupling their presence from CRT_LDBL_128BIT and instead checking for a CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is currently only set if long double is an IEEE 128-bit float. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D153812 | 2 年前 | |
[builtins] Move Windows/ARM frontends for fix/float functions into the individual source files This avoids pulling in all of them if only one of them is needed (if builtins are built without -ffunction-sections), and matches how the similar aliases for AEABI are set up. Differential Revision: https://reviews.llvm.org/D107815 | 4 年前 | |
[builtins] Use aliases for function redirects Symbol aliases are supported by all platforms that compiler-rt builtins target, and we can use these instead of function redirects to avoid the extra indirection. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60931 llvm-svn: 359413 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Move Windows/ARM frontends for fix/float functions into the individual source files This avoids pulling in all of them if only one of them is needed (if builtins are built without -ffunction-sections), and matches how the similar aliases for AEABI are set up. Differential Revision: https://reviews.llvm.org/D107815 | 4 年前 | |
[builtins] Use aliases for function redirects Symbol aliases are supported by all platforms that compiler-rt builtins target, and we can use these instead of function redirects to avoid the extra indirection. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60931 llvm-svn: 359413 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC Currently the *tf builtin functions can only be built if long double is an IEEE float, which prevents them from being available e.g. for x86 targets (unlike libgcc which has them). This non-functional change prepares the builtins library *tf functions for being able to target x86 by decoupling their presence from CRT_LDBL_128BIT and instead checking for a CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is currently only set if long double is an IEEE 128-bit float. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D153812 | 2 年前 | |
[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC Currently the *tf builtin functions can only be built if long double is an IEEE float, which prevents them from being available e.g. for x86 targets (unlike libgcc which has them). This non-functional change prepares the builtins library *tf functions for being able to target x86 by decoupling their presence from CRT_LDBL_128BIT and instead checking for a CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is currently only set if long double is an IEEE 128-bit float. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D153812 | 2 年前 | |
[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC Currently the *tf builtin functions can only be built if long double is an IEEE float, which prevents them from being available e.g. for x86 targets (unlike libgcc which has them). This non-functional change prepares the builtins library *tf functions for being able to target x86 by decoupling their presence from CRT_LDBL_128BIT and instead checking for a CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is currently only set if long double is an IEEE 128-bit float. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D153812 | 2 年前 | |
[builtins] Avoid using long double in generic sources (#69754) Use of long double can be error-prone since it could be one of 80-bit extended precision float, IEEE 128-bit float, or IBM 128-bit float. Instead use an explicit xf_float typedef for the remaining cases where long double is being used in the implementation. This patch does not touch the PPC specializations which still use long double. | 2 年前 | |
[builtins] Avoid using long double in generic sources (#69754) Use of long double can be error-prone since it could be one of 80-bit extended precision float, IEEE 128-bit float, or IBM 128-bit float. Instead use an explicit xf_float typedef for the remaining cases where long double is being used in the implementation. This patch does not touch the PPC specializations which still use long double. | 2 年前 | |
[builtins] Avoid using long double in generic sources (#69754) Use of long double can be error-prone since it could be one of 80-bit extended precision float, IEEE 128-bit float, or IBM 128-bit float. Instead use an explicit xf_float typedef for the remaining cases where long double is being used in the implementation. This patch does not touch the PPC specializations which still use long double. | 2 年前 | |
[builtins] Avoid using long double in generic sources (#69754) Use of long double can be error-prone since it could be one of 80-bit extended precision float, IEEE 128-bit float, or IBM 128-bit float. Instead use an explicit xf_float typedef for the remaining cases where long double is being used in the implementation. This patch does not touch the PPC specializations which still use long double. | 2 年前 | |
[builtins] Avoid using long double in generic sources (#69754) Use of long double can be error-prone since it could be one of 80-bit extended precision float, IEEE 128-bit float, or IBM 128-bit float. Instead use an explicit xf_float typedef for the remaining cases where long double is being used in the implementation. This patch does not touch the PPC specializations which still use long double. | 2 年前 | |
[builtins] Start to refactor int to fp conversion functions to use a common implementation (#66903) After this patch, the softfp implementations of floatdidf and floatundidf use a common implementation (int_to_fp.h and int_to_fp_impl.inc). This roughly follows the pattern used for a wide range of other builtins, e.g. fp_trunc_impl.inc. Currently there is substantial copy and paste for the various int to fp conversion functions, with just a few constants being changed. This is a barrier to maintainability, and it's also not attractive to copy this approach as we introduce additional int to fp conversion functions for bf16 and half (which we currently lack, but need - see <https://reviews.llvm.org/D157509>). I've opted to conservatively start by replacing just two functions, leaving a follow-up patch to replace others that follow the same pattern. Also, for better or worse I've left the logic in float[un]didf largely unchanged other than using a similar approach to fp_trunc_impl.inc to remove the constants that are tied to a specific output floating point format. | 2 年前 | |
[builtins] Convert more int to fp functions to use common implementation (#67540) Builds on #66903, converting the rest of the low-hanging fruit to use the common implementation. See https://github.com/llvm/llvm-project/pull/67540#issuecomment-1766499179 for links to Alive2 comparisons of before/after. | 2 年前 | |
[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC Currently the *tf builtin functions can only be built if long double is an IEEE float, which prevents them from being available e.g. for x86 targets (unlike libgcc which has them). This non-functional change prepares the builtins library *tf functions for being able to target x86 by decoupling their presence from CRT_LDBL_128BIT and instead checking for a CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is currently only set if long double is an IEEE 128-bit float. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D153812 | 2 年前 | |
[builtins] Avoid using long double in generic sources (#69754) Use of long double can be error-prone since it could be one of 80-bit extended precision float, IEEE 128-bit float, or IBM 128-bit float. Instead use an explicit xf_float typedef for the remaining cases where long double is being used in the implementation. This patch does not touch the PPC specializations which still use long double. | 2 年前 | |
[builtins] Avoid undefined behavior when calculating absolute value in floatsidf.c and floatsisf.c When compiling compiler-rt with -fsanitize=undefined and running testcases you end up with the following warning: UBSan: floatsidf.c:32:9: negation of -2147483648 cannot be represented in type 'si_int' (aka 'long'); cast to an unsigned type to negate this value to itself The same kind of pattern exists in floatsisf.c This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D146123 | 2 年前 | |
[builtins] Avoid undefined behavior when calculating absolute value in floatsidf.c and floatsisf.c When compiling compiler-rt with -fsanitize=undefined and running testcases you end up with the following warning: UBSan: floatsidf.c:32:9: negation of -2147483648 cannot be represented in type 'si_int' (aka 'long'); cast to an unsigned type to negate this value to itself The same kind of pattern exists in floatsisf.c This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D146123 | 2 年前 | |
[builtins] Avoid undefined behavior when calculating absolute value in floatsidf.c and floatsisf.c When compiling compiler-rt with -fsanitize=undefined and running testcases you end up with the following warning: UBSan: floatsidf.c:32:9: negation of -2147483648 cannot be represented in type 'si_int' (aka 'long'); cast to an unsigned type to negate this value to itself The same kind of pattern exists in floatsisf.c This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D146123 | 2 年前 | |
[builtins] Convert more int to fp functions to use common implementation (#67540) Builds on #66903, converting the rest of the low-hanging fruit to use the common implementation. See https://github.com/llvm/llvm-project/pull/67540#issuecomment-1766499179 for links to Alive2 comparisons of before/after. | 2 年前 | |
[builtins] Convert more int to fp functions to use common implementation (#67540) Builds on #66903, converting the rest of the low-hanging fruit to use the common implementation. See https://github.com/llvm/llvm-project/pull/67540#issuecomment-1766499179 for links to Alive2 comparisons of before/after. | 2 年前 | |
[builtins] Fix floattitf.c etc. compilation on Solaris/SPARC (#70058) 69660ccf2ae402b02799efed072afd8ecf5a6eb0 broke the [Solaris/sparcv9 buildbot](https://lab.llvm.org/staging/#/builders/12/builds/264): compiler-rt/lib/builtins/int_to_fp.h unconditionally uses *int128_t which don't exist on 32-bit SPARC. As suggested in https://github.com/llvm/llvm-project/pull/67540, this patch fixes this by moving the CRT_HAS_TF_MODE guard up which does the necessary checks. Tested on sparcv9-sun-solaris2.11. | 2 年前 | |
[builtins] Avoid using long double in generic sources (#69754) Use of long double can be error-prone since it could be one of 80-bit extended precision float, IEEE 128-bit float, or IBM 128-bit float. Instead use an explicit xf_float typedef for the remaining cases where long double is being used in the implementation. This patch does not touch the PPC specializations which still use long double. | 2 年前 | |
[builtins] Start to refactor int to fp conversion functions to use a common implementation (#66903) After this patch, the softfp implementations of floatdidf and floatundidf use a common implementation (int_to_fp.h and int_to_fp_impl.inc). This roughly follows the pattern used for a wide range of other builtins, e.g. fp_trunc_impl.inc. Currently there is substantial copy and paste for the various int to fp conversion functions, with just a few constants being changed. This is a barrier to maintainability, and it's also not attractive to copy this approach as we introduce additional int to fp conversion functions for bf16 and half (which we currently lack, but need - see <https://reviews.llvm.org/D157509>). I've opted to conservatively start by replacing just two functions, leaving a follow-up patch to replace others that follow the same pattern. Also, for better or worse I've left the logic in float[un]didf largely unchanged other than using a similar approach to fp_trunc_impl.inc to remove the constants that are tied to a specific output floating point format. | 2 年前 | |
[builtins] Convert more int to fp functions to use common implementation (#67540) Builds on #66903, converting the rest of the low-hanging fruit to use the common implementation. See https://github.com/llvm/llvm-project/pull/67540#issuecomment-1766499179 for links to Alive2 comparisons of before/after. | 2 年前 | |
[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC Currently the *tf builtin functions can only be built if long double is an IEEE float, which prevents them from being available e.g. for x86 targets (unlike libgcc which has them). This non-functional change prepares the builtins library *tf functions for being able to target x86 by decoupling their presence from CRT_LDBL_128BIT and instead checking for a CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is currently only set if long double is an IEEE 128-bit float. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D153812 | 2 年前 | |
[builtins] Avoid using long double in generic sources (#69754) Use of long double can be error-prone since it could be one of 80-bit extended precision float, IEEE 128-bit float, or IBM 128-bit float. Instead use an explicit xf_float typedef for the remaining cases where long double is being used in the implementation. This patch does not touch the PPC specializations which still use long double. | 2 年前 | |
[builtins] Support architectures with 16-bit int This is the first patch in a series to add support for the AVR target. This patch includes changes to make compiler-rt more target independent by not relying on the width of an int or long. Differential Revision: https://reviews.llvm.org/D78662 | 6 年前 | |
[compiler-rt][builtins] Use c[tl]zsi macro instead of __builtin_c[tl]z __builtin_c[tl]z accepts unsigned int argument that is not always the same as uint32_t. For example, unsigned int is uint16_t on MSP430. Reviewed By: aykevl Differential Revision: https://reviews.llvm.org/D86547 | 4 年前 | |
[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC Currently the *tf builtin functions can only be built if long double is an IEEE float, which prevents them from being available e.g. for x86 targets (unlike libgcc which has them). This non-functional change prepares the builtins library *tf functions for being able to target x86 by decoupling their presence from CRT_LDBL_128BIT and instead checking for a CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is currently only set if long double is an IEEE 128-bit float. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D153812 | 2 年前 | |
[builtins] Convert more int to fp functions to use common implementation (#67540) Builds on #66903, converting the rest of the low-hanging fruit to use the common implementation. See https://github.com/llvm/llvm-project/pull/67540#issuecomment-1766499179 for links to Alive2 comparisons of before/after. | 2 年前 | |
[builtins] Convert more int to fp functions to use common implementation (#67540) Builds on #66903, converting the rest of the low-hanging fruit to use the common implementation. See https://github.com/llvm/llvm-project/pull/67540#issuecomment-1766499179 for links to Alive2 comparisons of before/after. | 2 年前 | |
[builtins] Fix floattitf.c etc. compilation on Solaris/SPARC (#70058) 69660ccf2ae402b02799efed072afd8ecf5a6eb0 broke the [Solaris/sparcv9 buildbot](https://lab.llvm.org/staging/#/builders/12/builds/264): compiler-rt/lib/builtins/int_to_fp.h unconditionally uses *int128_t which don't exist on 32-bit SPARC. As suggested in https://github.com/llvm/llvm-project/pull/67540, this patch fixes this by moving the CRT_HAS_TF_MODE guard up which does the necessary checks. Tested on sparcv9-sun-solaris2.11. | 2 年前 | |
[builtins] Avoid using long double in generic sources (#69754) Use of long double can be error-prone since it could be one of 80-bit extended precision float, IEEE 128-bit float, or IBM 128-bit float. Instead use an explicit xf_float typedef for the remaining cases where long double is being used in the implementation. This patch does not touch the PPC specializations which still use long double. | 2 年前 | |
compiler-rt: fix few builtins build warnings. (#88991) | 2 年前 | |
[compiler-rt] Add initial ARM64EC builtins support (#139279) Use the aarch64 variants of assembly functions. Co-authored-by: Billy Laws <blaws05@gmail.com> | 1 年前 | |
[compiler-rt] Fix a bug in fp_div_impl when an intermediate result is out of expected range. (#119449) Before this fix, 1.0L / (1.0L - 0x1.0p-113L) will return 2 * (1 + eps(1)). | 1 年前 | |
[builtins] Use __builtin_clzll for 64-bit types (#99874) This addresses the issue with __LP64__ not being defined for targets with 32-bit pointers but 64-bit longs, resulting in worse codegen. | 2 年前 | |
[compiler-rt] On Windows, silence warning when building with latest MSVC This fixes: [3334/7449] Building C object projects\compiler-rt\lib\builtins\CMakeFiles\clang_rt.builtins-x86_64.dir\extendsfdf2.c.obj C:\git\llvm-project\compiler-rt\lib\builtins\fp_extend_impl.inc(63): warning C4018: '<': signed/unsigned mismatch | 2 年前 | |
compiler-rt: fix few builtins build warnings. (#88991) | 2 年前 | |
[NFC][compiler-rt][builtins] Tidy and match comments for floating point operations Differential Revision: https://reviews.llvm.org/D61762 llvm-svn: 360389 | 7 年前 | |
[compiler-rt] Add initial ARM64EC builtins support (#139279) Use the aarch64 variants of assembly functions. Co-authored-by: Billy Laws <blaws05@gmail.com> | 1 年前 | |
Add some prototypes to these functions; NFC This is expected to fix the issues in this build bot: https://lab.llvm.org/buildbot/#/builders/37/builds/12312 | 4 年前 | |
[NFC] Fix endif comments to match with include guard | 4 年前 | |
[NFC][compiler-rt][builtins] Tidy and match comments for floating point operations Differential Revision: https://reviews.llvm.org/D61762 llvm-svn: 360389 | 7 年前 | |
| 1 年前 | ||
[compiler-rt] Implement __extendxftf2 and __trunctfxf2 for x86_64 (#66918) This patch implements __extendxftf2 (long double -> f128) and __trunctfxf2 (f128 -> long double) on x86_64. This is a preparation to unblock https://reviews.llvm.org/D53608, We intentionally do not modify compiler-rt/lib/builtins/fp_lib.h in this PR (in particular, to limit the scope and avoid exposing other functions on X86_64 in this PR). Instead, TODOs were added to use fp_lib.h once it is available. Test plan: 1. ninja check-compiler-rt (verified on X86_64 and on Aarch64) In particular, new tests (extendxftf2_test.c and trunctfxf2_test.c) were added. 2. compared the results of conversions with what other compilers (gcc) produce. | 2 年前 | |
[PAC][libunwind] Fix gcc build of libunwind and compiler-rt (#164535) This adds guards on the ptrauth feature checks so that they are only performed if __has_feature is actually available. | 9 个月前 | |
Fix PR47973: Addressing integer division edge case with INT_MIN Adjustment to integer division in int_div_impl.inc to avoid undefined behaviour that can occur as a result of having INT_MIN as one of the parameters. Reviewed By: sepavloff Differential Revision: https://reviews.llvm.org/D90218 | 5 年前 | |
[compiler-rt] Remove mentions of AuroraUX in code comments and docs. AuroraUX was an operating system project based on an OpenSolaris kernel and an Ada userland. There appear to be no public code or release available online anymore. The project page on Wikipedia [1] was deleted in January 2012, and a news item [2] from November 2012 has more details. [1] https://en.wikipedia.org/w/index.php?title=Special:Log/delete&page=AuroraUX [2] https://www.phoronix.com/scan.php?page=news_item&px=MTIyMTI | 4 年前 | |
[compiler-rt] allow building with uefi (#131499) I'm trying to put together an LLVM built toolchain (including LLVM libc) targeting UEFI, currently I get an error saying "Unknown target". This PR enables compiling compiler-rt for UEFI. | 1 年前 | |
[compiler-rt] Stop using x86 builtin on AArch64 with GCC (#93890) Previously, building multc3.c on A64 with GCC 7 or up but 9 and lower will attempt to reference __builtin_copysignq, an [x86-specific intrinsic][1]: $ gcc -c multc3.c In file included from fp_lib.h:24, from multc3.c:14: multc3.c: In function '__multc3': int_math.h:71:32: warning: implicit declaration of function '__builtin_copysignq'; did you mean '__builtin_copysign'? [-Wimplicit-function-declaration] #define crt_copysignf128(x, y) __builtin_copysignq((x), (y)) ^~~~~~~~~~~~~~~~~~~ This is because __has_builtin is from GCC 10, and defined to 0 at the top of int_math.h for affected GCC versions, so the fallback definition is used. But __builtin_copysignq is unavailable on A64. Use version detection to find __builtin_copysignf128 instead. It's available since GCC 7 and [available][2] on both x86 and A64, given this macro is only used when CRT_HAS_IEEE_TF. --- I realize this is fixing a problem for an out-of-tree build configuration, but help would be greatly appreciated. Rust [builds](https://github.com/rust-lang/compiler-builtins) multc3.c with GCC 8 and this mis-selection is causing [build issues](https://github.com/rust-lang/rust/issues/125619) way downstream. ref: d2ce3e9621411f3391def327f89e3a650918989f [1]: https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html [2]: https://gcc.gnu.org/gcc-7/changes.html | 1 年前 | |
[compiler-rt] Fix signed integer overflow in int_mulo_impl.inc When compiling compiler-rt with -fsanitize=undefined and running testcases you end up with the following warning: UBSan:/repo/uabkaka/llvm-project/compiler-rt/lib/builtins/int_mulo_impl.inc:24:23: signed integer overflow: -1 * -2147483648 cannot be represented in type 'si_int' (aka 'long') This can be avoided by doing the multiplication in a matching unsigned variant of the type. This was found in an out of tree target. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D146623 | 3 年前 | |
[compiler-rt] Avoid signed shift overflow in __muloXi4 and __mulvXi3 When compiling compiler-rt with -fsanitize=undefined and running testcases you end up with the following warning: UBSan: int_mulo_impl.inc:21:36: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') This can be avoided by simply doing the shift in a matching unsigned variant of the type. The same kind of pattern seems to exist in int_mulv_impl.inc This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D145556 | 3 年前 | |
[builtins] Support building the 128-bit float functions on ld80 platforms (#68132) GCC provides these functions (e.g. __addtf3, etc.) in libgcc on x86_64. Since Clang supports float128, we can also enable the existing code by using float128 for fp_t if either __FLOAT128__ or __SIZEOF_FLOAT128__ is defined instead of only supporting these builtins for platforms with 128-bit IEEE long doubles. This commit defines a new tf_float typedef that matches a float with attribute((mode(TF)) on each given architecture. There are more tests that could be enabled for x86, but to keep the diff smaller, I restricted test changes to ones that started failing as part of this refactoring. This change has been tested on x86 (natively) and aarch64,powerpc64,riscv64 and sparc64 via qemu-user. This supersedes https://reviews.llvm.org/D98261 and should also cover the changes from https://github.com/llvm/llvm-project/pull/68041. | 2 年前 | |
| 2 年前 | ||
Reapply "compiler-rt: Introduce runtime functions for emulated PAC." This reverts commit 0c0aa56cdcf1fe3970a5f3875db412530512fc07. This time with the following fixes for buildbot failures: - Add underscore prefixes to symbol names on Apple platforms. - Modify the test so that it skips the crash tests on platforms where they are not expected to pass: - Platforms that implement FEAT_PAuth but not FEAT_FPAC (e.g. Apple M1, Cortex-A78C) - Platforms where DA key is disabled (e.g. older Linux kernels, Linux kernels with PAC disabled, likely Windows) Original commit message follows: The emulated PAC runtime functions emulate the ARMv8.3a pointer authentication instructions and are intended for use in heterogeneous testing environments. For more information, see the associated RFC: https://discourse.llvm.org/t/rfc-emulated-pac/85557 Reviewers: mstorsjo, pawosm-arm, atrosinenko Reviewed By: atrosinenko Pull Request: https://github.com/llvm/llvm-project/pull/148094 | 1 年前 | |
Fix Windows builders after 244601f4720d9cda6e81ea1908f3ce905a4bcb0e Apparently __builtin_abort() is not supported when targetting Windows. This should fix the following builder errors: clang_rt.builtins-x86_64.lib(int_util.c.obj) : error LNK2019: unresolved external symbol __builtin_abort referenced in function __compilerrt_abort_impl | 5 年前 | |
[builtins] Unify the softfloat division implementation This patch replaces three different pre-existing implementations of __div[sdt]f3 LibCalls with a generic one - like it is already done for many other LibCalls. Reviewed By: sepavloff Differential Revision: https://reviews.llvm.org/D85031 | 5 年前 | |
[builtins] Support architectures with 16-bit int This is the first patch in a series to add support for the AVR target. This patch includes changes to make compiler-rt more target independent by not relying on the width of an int or long. Differential Revision: https://reviews.llvm.org/D78662 | 6 年前 | |
[builtins] Support architectures with 16-bit int in __ashlti3, __ashrti3 and __lshrti3 The amount to shift should be specified by the int type not a 32-bit integer type. This patch change the functions for 128-bit shifts in compiler-rt the same way as was done for 64-bit shifts in D78662. The README.txt is updated with the shift builtins signatures from this patch and D78662. Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D146960 | 3 年前 | |
[NFC][compiler-rt] Factor out __div[sdt]i3 and __mod[dt]i3 implementations Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D86400 | 5 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[NFC][compiler-rt] Factor out __div[sdt]i3 and __mod[dt]i3 implementations Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D86400 | 5 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use aliases for function redirects Symbol aliases are supported by all platforms that compiler-rt builtins target, and we can use these instead of function redirects to avoid the extra indirection. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60931 llvm-svn: 359413 | 7 年前 | |
[builtins] Use aliases for function redirects Symbol aliases are supported by all platforms that compiler-rt builtins target, and we can use these instead of function redirects to avoid the extra indirection. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60931 llvm-svn: 359413 | 7 年前 | |
[compiler-rt] Avoid signed shift overflow in __muloXi4 and __mulvXi3 When compiling compiler-rt with -fsanitize=undefined and running testcases you end up with the following warning: UBSan: int_mulo_impl.inc:21:36: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') This can be avoided by simply doing the shift in a matching unsigned variant of the type. The same kind of pattern seems to exist in int_mulv_impl.inc This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D145556 | 3 年前 | |
[compiler-rt] Avoid signed shift overflow in __muloXi4 and __mulvXi3 When compiling compiler-rt with -fsanitize=undefined and running testcases you end up with the following warning: UBSan: int_mulo_impl.inc:21:36: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') This can be avoided by simply doing the shift in a matching unsigned variant of the type. The same kind of pattern seems to exist in int_mulv_impl.inc This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D145556 | 3 年前 | |
[compiler-rt] Avoid signed shift overflow in __muloXi4 and __mulvXi3 When compiling compiler-rt with -fsanitize=undefined and running testcases you end up with the following warning: UBSan: int_mulo_impl.inc:21:36: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') This can be avoided by simply doing the shift in a matching unsigned variant of the type. The same kind of pattern seems to exist in int_mulv_impl.inc This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D145556 | 3 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use aliases for function redirects Symbol aliases are supported by all platforms that compiler-rt builtins target, and we can use these instead of function redirects to avoid the extra indirection. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60931 llvm-svn: 359413 | 7 年前 | |
[builtins] Fix divtc3.c etc. compilation on Solaris/SPARC with gcc (#101662) compiler-rt/lib/builtins/divtc3.c and multc3.c don't compile on Solaris/sparcv9 with gcc -m32: FAILED: projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.builtins-sparc.dir/divtc3.c.o [...] compiler-rt/lib/builtins/divtc3.c: In function ‘__divtc3’: compiler-rt/lib/builtins/divtc3.c:22:18: error: implicit declaration of function ‘__compiler_rt_logbtf’ [-Wimplicit-function-declaration] 22 | fp_t __logbw = __compiler_rt_logbtf( | ^~~~~~~~~~~~~~~~~~~~ and many more. It turns out that while the definition of __divtc3 is guarded with CRT_HAS_F128, the __compiler_rt_logbtf and other declarations use CRT_HAS_128BIT && CRT_HAS_F128 as guard. This only shows up with gcc since, as documented in Issue #41838, clang violates the SPARC psABI in not using 128-bit long double, so this code path isn't used. Fixed by changing the guards to match. Tested on sparcv9-sun-solaris2.11. | 1 年前 | |
[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC Currently the *tf builtin functions can only be built if long double is an IEEE float, which prevents them from being available e.g. for x86 targets (unlike libgcc which has them). This non-functional change prepares the builtins library *tf functions for being able to target x86 by decoupling their presence from CRT_LDBL_128BIT and instead checking for a CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is currently only set if long double is an IEEE 128-bit float. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D153812 | 2 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[compiler-rt] Avoid signed shift overflow in __muloXi4 and __mulvXi3 When compiling compiler-rt with -fsanitize=undefined and running testcases you end up with the following warning: UBSan: int_mulo_impl.inc:21:36: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') This can be avoided by simply doing the shift in a matching unsigned variant of the type. The same kind of pattern seems to exist in int_mulv_impl.inc This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D145556 | 3 年前 | |
[compiler-rt] Avoid signed shift overflow in __muloXi4 and __mulvXi3 When compiling compiler-rt with -fsanitize=undefined and running testcases you end up with the following warning: UBSan: int_mulo_impl.inc:21:36: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') This can be avoided by simply doing the shift in a matching unsigned variant of the type. The same kind of pattern seems to exist in int_mulv_impl.inc This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D145556 | 3 年前 | |
[compiler-rt] Avoid signed shift overflow in __muloXi4 and __mulvXi3 When compiling compiler-rt with -fsanitize=undefined and running testcases you end up with the following warning: UBSan: int_mulo_impl.inc:21:36: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') This can be avoided by simply doing the shift in a matching unsigned variant of the type. The same kind of pattern seems to exist in int_mulv_impl.inc This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D145556 | 3 年前 | |
[builtins] Avoid using long double in generic sources (#69754) Use of long double can be error-prone since it could be one of 80-bit extended precision float, IEEE 128-bit float, or IBM 128-bit float. Instead use an explicit xf_float typedef for the remaining cases where long double is being used in the implementation. This patch does not touch the PPC specializations which still use long double. | 2 年前 | |
[builtins] Use aliases for function redirects Symbol aliases are supported by all platforms that compiler-rt builtins target, and we can use these instead of function redirects to avoid the extra indirection. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60931 llvm-svn: 359413 | 7 年前 | |
[builtins] Fix undefined behavior in negdi2.c and negti2.c When compiling the builtins with the undefined behavior sanitizer and running testcases you end up with the following warning: UBSan: negdi2.c:20:10: negation of -9223372036854775808 cannot be represented in type 'di_int' (aka 'long long'); cast to an unsigned type to negate this value to itself This can be avoided by doing negation in a matching unsigned variant of the type. The same kind of pattern is found in negti2.c This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D158818 | 2 年前 | |
[builtins] Use aliases for function redirects Symbol aliases are supported by all platforms that compiler-rt builtins target, and we can use these instead of function redirects to avoid the extra indirection. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60931 llvm-svn: 359413 | 7 年前 | |
[builtins] Fix undefined behavior in negdi2.c and negti2.c When compiling the builtins with the undefined behavior sanitizer and running testcases you end up with the following warning: UBSan: negdi2.c:20:10: negation of -9223372036854775808 cannot be represented in type 'di_int' (aka 'long long'); cast to an unsigned type to negate this value to itself This can be avoided by doing negation in a matching unsigned variant of the type. The same kind of pattern is found in negti2.c This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D158818 | 2 年前 | |
[compiler-rt] Fix signed shift overflows in absvdi2.c, absvsi2.c, negvdi2.c and negvsi2.c When compiling compiler-rt with -fsanitize=undefined and running testcases you end up with the following warnings: UBSan: absvdi2.c:21:23: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') UBSan: absvsi2.c:21:23: left shift of 1 by 31 places cannot be represented in type 'si_int' (aka 'long') UBSan: negvdi2.c:20:32: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') UBSan: negvsi2.c:20:32: left shift of 1 by 31 places cannot be represented in type 'si_int' (aka 'long') This can be avoided by doing the shift in a matching unsigned variant of the type. This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D146932 | 3 年前 | |
[compiler-rt] Fix signed shift overflows in absvdi2.c, absvsi2.c, negvdi2.c and negvsi2.c When compiling compiler-rt with -fsanitize=undefined and running testcases you end up with the following warnings: UBSan: absvdi2.c:21:23: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') UBSan: absvsi2.c:21:23: left shift of 1 by 31 places cannot be represented in type 'si_int' (aka 'long') UBSan: negvdi2.c:20:32: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long') UBSan: negvsi2.c:20:32: left shift of 1 by 31 places cannot be represented in type 'si_int' (aka 'long') This can be avoided by doing the shift in a matching unsigned variant of the type. This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D146932 | 3 年前 | |
[builtins] Fix signed shift overflows in absvti2.c and negvti2.c When compiling the builtins with the undefined behavior sanitizer and running testcases you end up with the following warning: UBSan: negvti2.c:22:32: left shift of 1 by 127 places cannot be represented in type 'ti_int' (aka '__int128') UBSan: absvti2.c:23:23: left shift of 1 by 127 places cannot be represented in type 'ti_int' (aka '__int128') This can be avoided by doing the shift in a matching unsigned variant of the type. This is the same kind of fixes that already was done in commit 854686f0794b9d0695d5a0a85ea1e7e71ba8edfd This was found in an out of tree target. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D158816 | 2 年前 | |
[compiler-rt][builtins] Upstream __isPlatformOrVariantPlatformVersionAtLeast() (#100605) Add __isPlatformOrVariantPlatformVersionAtLeast() which is used to check OS version availability from zippered libraries on macOS. This routine is needed for complete macCatalyst support in the Swift compiler. | 1 年前 | |
[builtins] Inline __paritysi2 into __paritydi2 and inline __paritydi2 into __parityti2. No point in making __parityti2 go through 2 calls to get to __paritysi2. Reviewed By: MaskRay, efriedma Differential Revision: https://reviews.llvm.org/D87218 | 5 年前 | |
[builtins] Change si_int to int in some helper declarations This patch changes types of some integer function arguments or return values from si_int to the default int type to make it more compatible with libgcc. The compiler-rt/lib/builtins/README.txt has a link to the [libgcc specification](http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc). This specification has an explicit note on int, float and other such types being just illustrations in some cases while the actual types are expressed with machine modes. Such usage of always-32-bit-wide integer type may lead to issues on 16-bit platforms such as MSP430. Provided [libgcc2.h](https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/libgcc2.h;hb=HEAD) can be used as a reference for all targets supported by the libgcc, this patch fixes some existing differences in helper declarations. This patch is expected to not change behavior at all for targets with 32-bit int type. Differential Revision: https://reviews.llvm.org/D81285 | 5 年前 | |
[builtins] Inline __paritysi2 into __paritydi2 and inline __paritydi2 into __parityti2. No point in making __parityti2 go through 2 calls to get to __paritysi2. Reviewed By: MaskRay, efriedma Differential Revision: https://reviews.llvm.org/D87218 | 5 年前 | |
[builtins] Support architectures with 16-bit int This is the first patch in a series to add support for the AVR target. This patch includes changes to make compiler-rt more target independent by not relying on the width of an int or long. Differential Revision: https://reviews.llvm.org/D78662 | 6 年前 | |
[builtins] Change si_int to int in some helper declarations This patch changes types of some integer function arguments or return values from si_int to the default int type to make it more compatible with libgcc. The compiler-rt/lib/builtins/README.txt has a link to the [libgcc specification](http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc). This specification has an explicit note on int, float and other such types being just illustrations in some cases while the actual types are expressed with machine modes. Such usage of always-32-bit-wide integer type may lead to issues on 16-bit platforms such as MSP430. Provided [libgcc2.h](https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/libgcc2.h;hb=HEAD) can be used as a reference for all targets supported by the libgcc, this patch fixes some existing differences in helper declarations. This patch is expected to not change behavior at all for targets with 32-bit int type. Differential Revision: https://reviews.llvm.org/D81285 | 5 年前 | |
[builtins] Change si_int to int in some helper declarations This patch changes types of some integer function arguments or return values from si_int to the default int type to make it more compatible with libgcc. The compiler-rt/lib/builtins/README.txt has a link to the [libgcc specification](http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc). This specification has an explicit note on int, float and other such types being just illustrations in some cases while the actual types are expressed with machine modes. Such usage of always-32-bit-wide integer type may lead to issues on 16-bit platforms such as MSP430. Provided [libgcc2.h](https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/libgcc2.h;hb=HEAD) can be used as a reference for all targets supported by the libgcc, this patch fixes some existing differences in helper declarations. This patch is expected to not change behavior at all for targets with 32-bit int type. Differential Revision: https://reviews.llvm.org/D81285 | 5 年前 | |
[builtins] Change si_int to int in some helper declarations This patch changes types of some integer function arguments or return values from si_int to the default int type to make it more compatible with libgcc. The compiler-rt/lib/builtins/README.txt has a link to the [libgcc specification](http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc). This specification has an explicit note on int, float and other such types being just illustrations in some cases while the actual types are expressed with machine modes. Such usage of always-32-bit-wide integer type may lead to issues on 16-bit platforms such as MSP430. Provided [libgcc2.h](https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/libgcc2.h;hb=HEAD) can be used as a reference for all targets supported by the libgcc, this patch fixes some existing differences in helper declarations. This patch is expected to not change behavior at all for targets with 32-bit int type. Differential Revision: https://reviews.llvm.org/D81285 | 5 年前 | |
[builtins] Change si_int to int in some helper declarations This patch changes types of some integer function arguments or return values from si_int to the default int type to make it more compatible with libgcc. The compiler-rt/lib/builtins/README.txt has a link to the [libgcc specification](http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc). This specification has an explicit note on int, float and other such types being just illustrations in some cases while the actual types are expressed with machine modes. Such usage of always-32-bit-wide integer type may lead to issues on 16-bit platforms such as MSP430. Provided [libgcc2.h](https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/libgcc2.h;hb=HEAD) can be used as a reference for all targets supported by the libgcc, this patch fixes some existing differences in helper declarations. This patch is expected to not change behavior at all for targets with 32-bit int type. Differential Revision: https://reviews.llvm.org/D81285 | 5 年前 | |
[builtins] Support building the 128-bit float functions on ld80 platforms (#68132) GCC provides these functions (e.g. __addtf3, etc.) in libgcc on x86_64. Since Clang supports float128, we can also enable the existing code by using float128 for fp_t if either __FLOAT128__ or __SIZEOF_FLOAT128__ is defined instead of only supporting these builtins for platforms with 128-bit IEEE long doubles. This commit defines a new tf_float typedef that matches a float with attribute((mode(TF)) on each given architecture. There are more tests that could be enabled for x86, but to keep the diff smaller, I restricted test changes to ones that started failing as part of this refactoring. This change has been tested on x86 (natively) and aarch64,powerpc64,riscv64 and sparc64 via qemu-user. This supersedes https://reviews.llvm.org/D98261 and should also cover the changes from https://github.com/llvm/llvm-project/pull/68041. | 2 年前 | |
[builtins] Avoid using long double in generic sources (#69754) Use of long double can be error-prone since it could be one of 80-bit extended precision float, IEEE 128-bit float, or IBM 128-bit float. Instead use an explicit xf_float typedef for the remaining cases where long double is being used in the implementation. This patch does not touch the PPC specializations which still use long double. | 2 年前 | |
Revert "Revert "[builtins] Rounding mode support for addxf3/subxf3"" Test failure fixed. This reverts commit e204d244badb2e9765a1020f41c773f63da208f4. llvm-svn: 371003 | 6 年前 | |
Revert "Revert "[builtins] Rounding mode support for addxf3/subxf3"" Test failure fixed. This reverts commit e204d244badb2e9765a1020f41c773f63da208f4. llvm-svn: 371003 | 6 年前 | |
[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC Currently the *tf builtin functions can only be built if long double is an IEEE float, which prevents them from being available e.g. for x86 targets (unlike libgcc which has them). This non-functional change prepares the builtins library *tf functions for being able to target x86 by decoupling their presence from CRT_LDBL_128BIT and instead checking for a CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is currently only set if long double is an IEEE 128-bit float. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D153812 | 2 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[AArch64] fix trampoline implementation: use X15 (#126743) AAPCS64 reserves any of X9-X15 for a compiler to choose to use for this purpose, and says not to use X16 or X18 like GCC (and the previous implementation) chose to use. The X18 register may need to get used by the kernel in some circumstances, as specified by the platform ABI, so it is generally an unwise choice. Simply choosing a different register fixes the problem of this being broken on any platform that actually follows the platform ABI (which is all of them except EABI, if I am reading this linux kernel bug correctly https://lkml2.uits.iu.edu/hypermail/linux/kernel/2001.2/01502.html). As a side benefit, also generate slightly better code and avoids needing the compiler-rt to be present. I did that by following the XCore implementation instead of PPC (although in hindsight, following the RISCV might have been slightly more readable). That X18 is wrong to use for this purpose has been known for many years (e.g. https://www.mail-archive.com/gcc@gcc.gnu.org/msg76934.html) and also known that fixing this to use one of the correct registers is not an ABI break, since this only appears inside of a translation unit. Some of the other temporary registers (e.g. X9) are already reserved inside llvm for internal use as a generic temporary register in the prologue before saving registers, while X15 was already used in rare cases as a scratch register in the prologue as well, so I felt that seemed the most logical choice to choose here. | 1 年前 | |
Revert "Reland "[compiler-rt][BF16] Provide __truncsfbf2 only when __bf16 is available"" This reverts commit 0729d00135ccbe1514a49168bbf26986823235c2. Buildbot https://lab.llvm.org/buildbot/#/builders/19/builds/11989 failed with "error: ISO C requires a translation unit to contain at least one declaration [-Werror,-Wempty-translation-unit]" | 3 年前 | |
[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 | 5 年前 | |
[builtins] Use aliases for function redirects Symbol aliases are supported by all platforms that compiler-rt builtins target, and we can use these instead of function redirects to avoid the extra indirection. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60931 llvm-svn: 359413 | 7 年前 | |
Revert "Reland "[compiler-rt][BF16] Provide __truncsfbf2 only when __bf16 is available"" This reverts commit 0729d00135ccbe1514a49168bbf26986823235c2. Buildbot https://lab.llvm.org/buildbot/#/builders/19/builds/11989 failed with "error: ISO C requires a translation unit to contain at least one declaration [-Werror,-Wempty-translation-unit]" | 3 年前 | |
[builtins][AArch32] Fix __gnu_* functions (#137638) Move to a consistent calling convention for both Clang/GNU such that they can be linked with each other. All ARM targets now use the soft-float calling convention for __gnu_h2f_ieee and __gnu_f2h_ieee, as described in https://github.com/ARM-software/abi-aa/blob/main/rtabi32/rtabi32.rst#the-floating-point-helper-functions. | 1 年前 | |
compiler-rt/lib: Fix newline at eof | 1 年前 | |
[builtins] Support building the 128-bit float functions on ld80 platforms (#68132) GCC provides these functions (e.g. __addtf3, etc.) in libgcc on x86_64. Since Clang supports float128, we can also enable the existing code by using float128 for fp_t if either __FLOAT128__ or __SIZEOF_FLOAT128__ is defined instead of only supporting these builtins for platforms with 128-bit IEEE long doubles. This commit defines a new tf_float typedef that matches a float with attribute((mode(TF)) on each given architecture. There are more tests that could be enabled for x86, but to keep the diff smaller, I restricted test changes to ones that started failing as part of this refactoring. This change has been tested on x86 (natively) and aarch64,powerpc64,riscv64 and sparc64 via qemu-user. This supersedes https://reviews.llvm.org/D98261 and should also cover the changes from https://github.com/llvm/llvm-project/pull/68041. | 2 年前 | |
[builtins] Support building the 128-bit float functions on ld80 platforms (#68132) GCC provides these functions (e.g. __addtf3, etc.) in libgcc on x86_64. Since Clang supports float128, we can also enable the existing code by using float128 for fp_t if either __FLOAT128__ or __SIZEOF_FLOAT128__ is defined instead of only supporting these builtins for platforms with 128-bit IEEE long doubles. This commit defines a new tf_float typedef that matches a float with attribute((mode(TF)) on each given architecture. There are more tests that could be enabled for x86, but to keep the diff smaller, I restricted test changes to ones that started failing as part of this refactoring. This change has been tested on x86 (natively) and aarch64,powerpc64,riscv64 and sparc64 via qemu-user. This supersedes https://reviews.llvm.org/D98261 and should also cover the changes from https://github.com/llvm/llvm-project/pull/68041. | 2 年前 | |
[builtins] Support building the 128-bit float functions on ld80 platforms (#68132) GCC provides these functions (e.g. __addtf3, etc.) in libgcc on x86_64. Since Clang supports float128, we can also enable the existing code by using float128 for fp_t if either __FLOAT128__ or __SIZEOF_FLOAT128__ is defined instead of only supporting these builtins for platforms with 128-bit IEEE long doubles. This commit defines a new tf_float typedef that matches a float with attribute((mode(TF)) on each given architecture. There are more tests that could be enabled for x86, but to keep the diff smaller, I restricted test changes to ones that started failing as part of this refactoring. This change has been tested on x86 (natively) and aarch64,powerpc64,riscv64 and sparc64 via qemu-user. This supersedes https://reviews.llvm.org/D98261 and should also cover the changes from https://github.com/llvm/llvm-project/pull/68041. | 2 年前 | |
[builtins] Avoid using long double in generic sources (#69754) Use of long double can be error-prone since it could be one of 80-bit extended precision float, IEEE 128-bit float, or IBM 128-bit float. Instead use an explicit xf_float typedef for the remaining cases where long double is being used in the implementation. This patch does not touch the PPC specializations which still use long double. | 2 年前 | |
[compiler-rt] Fix a warning This patch fixes: compiler-rt/lib/builtins/truncxfbf2.c:16:7: error: ISO C requires a translation unit to contain at least one declaration [-Werror,-Wempty-translation-unit] | 1 年前 | |
| 1 年前 | ||
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Make __umodsi3/__udivdi3/__umoddi3 standalone (shift and subtract) @kamleshbhalui reported that when the Standard Extension M (Multiplication and Division) is disabled for RISC-V, __udivdi3 will call __udivmodti4 which will in turn calls __udivdi3. This patch moves __udivsi3 (shift and subtract) to int_div_impl.inc __udivXi3, optimize a bit, add a __umodXi3, and use __udivXi3 and __umodXi3 to define __udivsi3 __umodsi3 __udivdi3 __umoddi3. Reviewed By: kamleshbhalui Differential Revision: https://reviews.llvm.org/D77912 | 6 年前 | |
[compiler-rt][builtins] Use c[tl]zsi macro instead of __builtin_c[tl]z __builtin_c[tl]z accepts unsigned int argument that is not always the same as uint32_t. For example, unsigned int is uint16_t on MSP430. Reviewed By: aykevl Differential Revision: https://reviews.llvm.org/D86547 | 4 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[compiler-rt] Add initial ARM64EC builtins support (#139279) Use the aarch64 variants of assembly functions. Co-authored-by: Billy Laws <blaws05@gmail.com> | 1 年前 | |
[builtins] Make __umodsi3/__udivdi3/__umoddi3 standalone (shift and subtract) @kamleshbhalui reported that when the Standard Extension M (Multiplication and Division) is disabled for RISC-V, __udivdi3 will call __udivmodti4 which will in turn calls __udivdi3. This patch moves __udivsi3 (shift and subtract) to int_div_impl.inc __udivXi3, optimize a bit, add a __umodXi3, and use __udivXi3 and __umodXi3 to define __udivsi3 __umodsi3 __udivdi3 __umoddi3. Reviewed By: kamleshbhalui Differential Revision: https://reviews.llvm.org/D77912 | 6 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Make __umodsi3/__udivdi3/__umoddi3 standalone (shift and subtract) @kamleshbhalui reported that when the Standard Extension M (Multiplication and Division) is disabled for RISC-V, __udivdi3 will call __udivmodti4 which will in turn calls __udivdi3. This patch moves __udivsi3 (shift and subtract) to int_div_impl.inc __udivXi3, optimize a bit, add a __umodXi3, and use __udivXi3 and __umodXi3 to define __udivsi3 __umodsi3 __udivdi3 __umoddi3. Reviewed By: kamleshbhalui Differential Revision: https://reviews.llvm.org/D77912 | 6 年前 | |
[builtins] Make __umodsi3/__udivdi3/__umoddi3 standalone (shift and subtract) @kamleshbhalui reported that when the Standard Extension M (Multiplication and Division) is disabled for RISC-V, __udivdi3 will call __udivmodti4 which will in turn calls __udivdi3. This patch moves __udivsi3 (shift and subtract) to int_div_impl.inc __udivXi3, optimize a bit, add a __umodXi3, and use __udivXi3 and __umodXi3 to define __udivsi3 __umodsi3 __udivdi3 __umoddi3. Reviewed By: kamleshbhalui Differential Revision: https://reviews.llvm.org/D77912 | 6 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 | |
[builtins] Use single line C++/C99 comment style Use the uniform single line C++/99 style for code comments. This is part of the cleanup proposed in "[RFC] compiler-rt builtins cleanup and refactoring". Differential Revision: https://reviews.llvm.org/D60352 llvm-svn: 359411 | 7 年前 |
Compiler-RT
This directory and its subdirectories contain source code for the compiler support routines.
Compiler-RT is open source software. You may freely distribute it under the terms of the license agreement found in LICENSE.txt.
================================
This is a replacement library for libgcc. Each function is contained in its own file. Each function has a corresponding unit test under test/Unit.
A rudimentary script to test each file is in the file called test/Unit/test.
Here is the specification for this library:
http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc
Please note that the libgcc specification explicitly mentions actual types of arguments and returned values being expressed with machine modes. In some cases particular types such as "int", "unsigned", "long long", etc. may be specified just as examples there.
Here is a synopsis of the contents of this library:
typedef int32_t si_int; typedef uint32_t su_int;
typedef int64_t di_int; typedef uint64_t du_int;
// Integral bit manipulation
di_int __ashldi3(di_int a, int b); // a << b ti_int __ashlti3(ti_int a, int b); // a << b
di_int __ashrdi3(di_int a, int b); // a >> b arithmetic (sign fill) ti_int __ashrti3(ti_int a, int b); // a >> b arithmetic (sign fill) di_int __lshrdi3(di_int a, int b); // a >> b logical (zero fill) ti_int __lshrti3(ti_int a, int b); // a >> b logical (zero fill)
int __clzsi2(si_int a); // count leading zeros int __clzdi2(di_int a); // count leading zeros int __clzti2(ti_int a); // count leading zeros int __ctzsi2(si_int a); // count trailing zeros int __ctzdi2(di_int a); // count trailing zeros int __ctzti2(ti_int a); // count trailing zeros
int __ffssi2(si_int a); // find least significant 1 bit int __ffsdi2(di_int a); // find least significant 1 bit int __ffsti2(ti_int a); // find least significant 1 bit
int __paritysi2(si_int a); // bit parity int __paritydi2(di_int a); // bit parity int __parityti2(ti_int a); // bit parity
int __popcountsi2(si_int a); // bit population int __popcountdi2(di_int a); // bit population int __popcountti2(ti_int a); // bit population
uint32_t __bswapsi2(uint32_t a); // a byteswapped uint64_t __bswapdi2(uint64_t a); // a byteswapped
// Integral arithmetic
di_int __negdi2 (di_int a); // -a ti_int __negti2 (ti_int a); // -a di_int __muldi3 (di_int a, di_int b); // a * b ti_int __multi3 (ti_int a, ti_int b); // a * b si_int __divsi3 (si_int a, si_int b); // a / b signed di_int __divdi3 (di_int a, di_int b); // a / b signed ti_int __divti3 (ti_int a, ti_int b); // a / b signed su_int __udivsi3 (su_int n, su_int d); // a / b unsigned du_int __udivdi3 (du_int a, du_int b); // a / b unsigned tu_int __udivti3 (tu_int a, tu_int b); // a / b unsigned si_int __modsi3 (si_int a, si_int b); // a % b signed di_int __moddi3 (di_int a, di_int b); // a % b signed ti_int __modti3 (ti_int a, ti_int b); // a % b signed su_int __umodsi3 (su_int a, su_int b); // a % b unsigned du_int __umoddi3 (du_int a, du_int b); // a % b unsigned tu_int __umodti3 (tu_int a, tu_int b); // a % b unsigned du_int __udivmoddi4(du_int a, du_int b, du_int* rem); // a / b, rem = a % b unsigned tu_int __udivmodti4(tu_int a, tu_int b, tu_int rem); // a / b, rem = a % b unsigned su_int __udivmodsi4(su_int a, su_int b, su_int rem); // a / b, rem = a % b unsigned si_int __divmodsi4(si_int a, si_int b, si_int rem); // a / b, rem = a % b signed di_int __divmoddi4(di_int a, di_int b, di_int rem); // a / b, rem = a % b signed ti_int __divmodti4(ti_int a, ti_int b, ti_int rem); // a / b, *rem = a % b signed
// Integral arithmetic with trapping overflow
si_int __absvsi2(si_int a); // abs(a) di_int __absvdi2(di_int a); // abs(a) ti_int __absvti2(ti_int a); // abs(a)
si_int __negvsi2(si_int a); // -a di_int __negvdi2(di_int a); // -a ti_int __negvti2(ti_int a); // -a
si_int __addvsi3(si_int a, si_int b); // a + b di_int __addvdi3(di_int a, di_int b); // a + b ti_int __addvti3(ti_int a, ti_int b); // a + b
si_int __subvsi3(si_int a, si_int b); // a - b di_int __subvdi3(di_int a, di_int b); // a - b ti_int __subvti3(ti_int a, ti_int b); // a - b
si_int __mulvsi3(si_int a, si_int b); // a * b di_int __mulvdi3(di_int a, di_int b); // a * b ti_int __mulvti3(ti_int a, ti_int b); // a * b
// Integral arithmetic which returns if overflow
si_int __mulosi4(si_int a, si_int b, int* overflow); // a * b, overflow set to one if result not in signed range di_int __mulodi4(di_int a, di_int b, int* overflow); // a * b, overflow set to one if result not in signed range ti_int __muloti4(ti_int a, ti_int b, int* overflow); // a * b, overflow set to one if result not in signed range
// Integral comparison: a < b -> 0 // a == b -> 1 // a > b -> 2
si_int __cmpdi2 (di_int a, di_int b); si_int __cmpti2 (ti_int a, ti_int b); si_int __ucmpdi2(du_int a, du_int b); si_int __ucmpti2(tu_int a, tu_int b);
// Integral / floating point conversion
di_int __fixsfdi( float a); di_int __fixdfdi( double a); di_int __fixxfdi(long double a); di_int __fixtfdi( tf_float a);
ti_int __fixsfti( float a); ti_int __fixdfti( double a); ti_int __fixxfti(long double a); ti_int __fixtfti( tf_float a);
su_int __fixunssfsi( float a); su_int __fixunsdfsi( double a); su_int __fixunsxfsi(long double a); su_int __fixunstfsi( tf_float a);
du_int __fixunssfdi( float a); du_int __fixunsdfdi( double a); du_int __fixunsxfdi(long double a); du_int __fixunstfdi( tf_float a);
tu_int __fixunssfti( float a); tu_int __fixunsdfti( double a); tu_int __fixunsxfti(long double a); tu_int __fixunstfti( tf_float a);
float __floatdisf(di_int a); double __floatdidf(di_int a); long double __floatdixf(di_int a); tf_float __floatditf(int64_t a);
float __floattisf(ti_int a); double __floattidf(ti_int a); long double __floattixf(ti_int a); tf_float __floattitf(ti_int a);
float __floatundisf(du_int a); double __floatundidf(du_int a); long double __floatundixf(du_int a); tf_float __floatunditf(du_int a);
float __floatuntisf(tu_int a); double __floatuntidf(tu_int a); long double __floatuntixf(tu_int a); tf_float __floatuntixf(tu_int a);
// Floating point raised to integer power
float __powisf2( float a, int b); // a ^ b double __powidf2( double a, int b); // a ^ b long double __powixf2(long double a, int b); // a ^ b tf_float __powitf2( tf_float a, int b); // a ^ b
// Complex arithmetic
// (a + ib) * (c + id)
float _Complex __mulsc3( float a, float b, float c, float d);
double _Complex __muldc3(double a, double b, double c, double d);
long double _Complex __mulxc3(long double a, long double b, long double c, long double d); tf_float _Complex __multc3(tf_float a, tf_float b, tf_float c, tf_float d);
// (a + ib) / (c + id)
float _Complex __divsc3( float a, float b, float c, float d);
double _Complex __divdc3(double a, double b, double c, double d);
long double _Complex __divxc3(long double a, long double b, long double c, long double d); tf_float _Complex __divtc3(tf_float a, tf_float b, tf_float c, tf_float d);
// Runtime support
// __clear_cache() is used to tell process that new instructions have been // written to an address range. Necessary on processors that do not have // a unified instruction and data cache. void __clear_cache(void* start, void* end);
// __enable_execute_stack() is used with nested functions when a trampoline // function is written onto the stack and that page range needs to be made // executable. void __enable_execute_stack(void* addr);
// __gcc_personality_v0() is normally only called by the system unwinder.
// C code (as opposed to C++) normally does not need a personality function
// because there are no catch clauses or destructors to be run. But there
// is a C language extension attribute((cleanup(func))) which marks local
// variables as needing the cleanup function "func" to be run when the
// variable goes out of scope. That includes when an exception is thrown,
// so a personality handler is needed.
_Unwind_Reason_Code __gcc_personality_v0(int version, _Unwind_Action actions,
uint64_t exceptionClass, struct _Unwind_Exception* exceptionObject,
_Unwind_Context_t context);
// for use with some implementations of assert() in <assert.h> void __eprintf(const char* format, const char* assertion_expression, const char* line, const char* file);
// for systems with emulated thread local storage void* __emutls_get_address(struct __emutls_control*);
// Power PC specific functions
// There is no C interface to the saveFP/restFP functions. They are helper
// functions called by the prolog and epilog of functions that need to save
// a number of non-volatile float point registers.
saveFP
restFP
// PowerPC has a standard template for trampoline functions. This function // generates a custom trampoline function with the specific realFunc // and localsPtr values. void __trampoline_setup(uint32_t* trampOnStack, int trampSizeAllocated, const void* realFunc, void* localsPtr);
// adds two 128-bit double-double precision values ( x + y ) long double __gcc_qadd(long double x, long double y);
// subtracts two 128-bit double-double precision values ( x - y ) long double __gcc_qsub(long double x, long double y);
// multiples two 128-bit double-double precision values ( x * y ) long double __gcc_qmul(long double x, long double y);
// divides two 128-bit double-double precision values ( x / y ) long double __gcc_qdiv(long double a, long double b);
// ARM specific functions
// There is no C interface to the switch* functions. These helper functions // are only needed by Thumb1 code for efficient switch table generation. switch16 switch32 switch8 switchu8
// There is no C interface to the *_vfp_d8_d15_regs functions. There are // called in the prolog and epilog of Thumb1 functions. When the C++ ABI use // SJLJ for exceptions, each function with a catch clause or destructors needs // to save and restore all registers in it prolog and epilog. But there is // no way to access vector and high float registers from thumb1 code, so the // compiler must add call outs to these helper functions in the prolog and // epilog. restore_vfp_d8_d15_regs save_vfp_d8_d15_regs
// Note: long ago ARM processors did not have floating point hardware support. // Floating point was done in software and floating point parameters were // passed in integer registers. When hardware support was added for floating // point, new *vfp functions were added to do the same operations but with // floating point parameters in floating point registers.
// Undocumented functions
float __addsf3vfp(float a, float b); // Appears to return a + b double __adddf3vfp(double a, double b); // Appears to return a + b float __divsf3vfp(float a, float b); // Appears to return a / b double __divdf3vfp(double a, double b); // Appears to return a / b int __eqsf2vfp(float a, float b); // Appears to return one // iff a == b and neither is NaN. int __eqdf2vfp(double a, double b); // Appears to return one // iff a == b and neither is NaN. double __extendsfdf2vfp(float a); // Appears to convert from // float to double. int __fixdfsivfp(double a); // Appears to convert from // double to int. int __fixsfsivfp(float a); // Appears to convert from // float to int. unsigned int __fixunssfsivfp(float a); // Appears to convert from // float to unsigned int. unsigned int __fixunsdfsivfp(double a); // Appears to convert from // double to unsigned int. double __floatsidfvfp(int a); // Appears to convert from // int to double. float __floatsisfvfp(int a); // Appears to convert from // int to float. double __floatunssidfvfp(unsigned int a); // Appears to convert from // unsigned int to double. float __floatunssisfvfp(unsigned int a); // Appears to convert from // unsigned int to float. int __gedf2vfp(double a, double b); // Appears to return __gedf2 // (a >= b) int __gesf2vfp(float a, float b); // Appears to return __gesf2 // (a >= b) int __gtdf2vfp(double a, double b); // Appears to return __gtdf2 // (a > b) int __gtsf2vfp(float a, float b); // Appears to return __gtsf2 // (a > b) int __ledf2vfp(double a, double b); // Appears to return __ledf2 // (a <= b) int __lesf2vfp(float a, float b); // Appears to return __lesf2 // (a <= b) int __ltdf2vfp(double a, double b); // Appears to return __ltdf2 // (a < b) int __ltsf2vfp(float a, float b); // Appears to return __ltsf2 // (a < b) double __muldf3vfp(double a, double b); // Appears to return a * b float __mulsf3vfp(float a, float b); // Appears to return a * b int __nedf2vfp(double a, double b); // Appears to return __nedf2 // (a != b) double __negdf2vfp(double a); // Appears to return -a float __negsf2vfp(float a); // Appears to return -a float __negsf2vfp(float a); // Appears to return -a double __subdf3vfp(double a, double b); // Appears to return a - b float __subsf3vfp(float a, float b); // Appears to return a - b float __truncdfsf2vfp(double a); // Appears to convert from // double to float. int __unorddf2vfp(double a, double b); // Appears to return __unorddf2 int __unordsf2vfp(float a, float b); // Appears to return __unordsf2
Preconditions are listed for each function at the definition when there are any. Any preconditions reflect the specification at http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc.
Assumptions are listed in "int_lib.h", and in individual files. Where possible assumptions are checked at compile time.