summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/builtins
Commit message (Collapse)AuthorAgeFilesLines
* builtins: mark functions as aapcs on WindowsSaleem Abdulrasool2015-05-221-1/+5
| | | | | | | | Windows does not use AAPCS, but rather AAPCS-VFP, and thus the functions which are assumed to be AAPCS will cause invalid argument setup. Ensure that the functions are marked as AAPCS. llvm-svn: 238056
* [Builtins] Implement f2h/h2f by jumping to trunc/extend.Ahmed Bougacha2015-05-142-4/+8
| | | | | | | | | | | | Follow-up to r237161; seems like we can't use aliases, but we can do better than duplicating the bodies, especially when that body, after inlining, isn't as small as it looks. Better approaches welcome. Perhaps the best thing is just to have an #ifndef __APPLE__ over the GNUEABI names, since they're not used there. llvm-svn: 237323
* [Builtins] Implement half-precision conversions.Ahmed Bougacha2015-05-127-5/+92
| | | | | | | | | | | | | | | | | Mostly uninteresting, except: - in __extendXfYf2, when checking if the number is normal, the old code relied on the unsignedness of src_rep_t, which is a problem when sizeof(src_rep_t) < sizeof(int): the result gets promoted to int, the signedness of which breaks the comparison. I added an explicit cast; it shouldn't affect other types. - we can't pass __fp16, so src_t and src_rep_t are the same. - the gnu_*_ieee symbols are simply duplicated definitions, as aliases are problematic on mach-o (where only weak aliases are supported; that's not what we want). Differential Revision: http://reviews.llvm.org/D9693 llvm-svn: 237161
* builtins: Implement the functions from stdatomic.hJustin Bogner2015-05-086-0/+116
| | | | | | | | | | | Talking to John and Doug, we concluded that these functions from stdatomic really do belong here in compiler-rt rather than in libc, since the compiler owns stdatomic.h and these need to refer to clang-specific builtins. Nonetheless, I've only added these on darwin for now - other platforms should probably do the same unless their libc does implement these functions. llvm-svn: 236805
* Fix float->uint conversion for inputs less than 0Derek Schuff2015-05-013-1/+3
| | | | | | | | | | | | | | | | | | | | Summary: The spec for these functions says that they should return 0 in this case but this regressed in r234148. That revision essentially delegates the conversion to the hardware, but that has different behavior on different platforms (e.g. it is wrong on x86). Also fix a typo in the name of __fixunsdfti Test Plan: The existing unit tests now pass Reviewers: joerg, howard.hinnant Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9305 llvm-svn: 236319
* Add hard float versions of FP to LL conversionsSergey Dmitrouk2015-04-064-4/+97
| | | | | | | | | | | | | | | | | | | | | | | | | This adds hard-float implementation for the following builtins: * __fixdfdi() * __fixsfdi() * __fixunsdfdi() * __fixunssfdi() The soft-float implementation does never raise floating point exceptions, which doesn't allow clients to detect floating point conversion errors. I must mention that I had to refer to libgcc's implementation to write these functions. Related unit-tests of compiler-rt passed with these changes. Patch was somewhat out-dated, so was updated locally without any functional changes. Differential Revision: http://reviews.llvm.org/D5376 llvm-svn: 234148
* We want single precision here.Joerg Sonnenberger2015-03-131-0/+3
| | | | llvm-svn: 232125
* Use signed int implementation for __fixintEd Maste2015-03-123-3/+3
| | | | llvm-svn: 232107
* Be nicer to C90 environments and avoid the declaration of variables in forJoerg Sonnenberger2015-03-111-2/+3
| | | | | | | | header. From Alexander Esilevich. llvm-svn: 231975
* Always include stddef.h to make sure size_t exists.Joerg Sonnenberger2015-03-111-0/+1
| | | | | | From Alexander Esilevich. llvm-svn: 231972
* Refactor float to integer conversion to share the same code.Joerg Sonnenberger2015-03-1125-376/+329
| | | | | | | | | | | | | 80bit Intel/PPC long double is excluded due to lacking support for the abstraction. Consistently provide saturation logic. Extend to long double on 128bit IEEE extended platforms. Initial patch with test cases from GuanHong Liu. Reviewed by Steve Canon. Differential Revision: http://reviews.llvm.org/D2804 llvm-svn: 231965
* Allow compiler-rt build on BitrigRenato Golin2015-03-021-2/+2
| | | | | | | | | This is the only patch Bitrig uses for compiler-rt. It adds support for Bitrig/arm in the clear cache code. Patch by Patrick Wildt. llvm-svn: 231012
* [MIPS] Add missing header for syscallPetar Jovanovic2015-02-281-0/+1
| | | | | | | | | | The syscall function itself is declared in <unistd.h> Compiling compiler-rt with -Werror-implicit-function-declaration will cause a build failure. This change fixes it. Differential Revision: http://reviews.llvm.org/D7949 llvm-svn: 230838
* Use compiler provided endianness definitions if available.Ed Schouten2015-02-231-12/+16
| | | | | | | | This makes int_endianness.h work on operating systems for which we haven't written explicit constructs, as long as GCC or Clang are being used. llvm-svn: 230208
* [mips] Add __clear_cache() definition for non-Android systemsPetar Jovanovic2015-02-101-4/+4
| | | | | | | | | Make sure clear_cache() builtin has an appropriate definition for Linux. Call syscall(NR_cacheflush, ...). Differential Revision: http://reviews.llvm.org/D7205 llvm-svn: 228767
* Remove invalid const qualifier for r0, since it is written by svc.Stephen Hines2015-02-031-1/+1
| | | | | | | | | | | | | | Summary: This causes an invalid lvalue error when building for Android. Reviewers: danalbert Reviewed By: danalbert Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7306 llvm-svn: 227907
* [MIPS64] Make __clear_cache more optimalPetar Jovanovic2015-01-201-1/+56
| | | | | | | | | Use synci implementation of clear_cache for short address ranges. For long address ranges, make a kernel call. Differential Revision: http://reviews.llvm.org/D6661 llvm-svn: 226567
* Fix compilation of compiler_rt against libunwind.Evgeniy Stepanov2015-01-151-1/+1
| | | | | | | libunwind defines _Unwind_GetLanguageSpecificData as returning long instead of (uint8_t *). llvm-svn: 226167
* builtins: avoid duplicating unwind declarationsSaleem Abdulrasool2015-01-142-44/+9
| | | | | | | | | Use unwind.h to get the declarations for unwinding interfaces. This header is already provided by clang and gcc, so this adds no additional dependencies for building the builtins library. It avoids the duplication which may drift over time though. llvm-svn: 225990
* Add FreeBSD support for __clear_cache.Roman Divacky2015-01-111-1/+6
| | | | llvm-svn: 225610
* builtins: rely on the compiler for user label prefixSaleem Abdulrasool2014-12-191-12/+6
| | | | | | | | | | clang does not like the definition of builtins. In order to work around this, we use a SUN CC to redefine the generated name. However, this requires that we account for the user label prefix. Rather than hard coding that into the file, rely on the compiler to tell us the information and use the preprocessor to generate the name as we do in the assembly routines. NFC. llvm-svn: 224597
* Do not define CRT_HAS_128BIT for MIPS64Petar Jovanovic2014-12-181-1/+2
| | | | | | | | | | | Do not define it for MIPS64 until its backend supports it. See the bug report [1] for more information. [1] http://llvm.org/bugs/show_bug.cgi?id=20098 Differential Revision: http://reviews.llvm.org/D6703 llvm-svn: 224488
* builtins: cleanup constant data section selectionSaleem Abdulrasool2014-12-108-58/+14
| | | | | | | | | | Each of the object formats use a different directive for selecting the constant section. Use a macro to avoid the duplication across a number of files. Also correct a small macro mismatch on the Windows case (HIDDEN_DIRECTIVE -> HIDDEN). Patch by Vadim Chugunov! llvm-svn: 223910
* PR21518: Use unsigned arithmetic for trapping add/sub functions.Bob Wilson2014-11-126-6/+6
| | | | | | | | | | The code in {add,sub}v.i3 routines does not trap when it should, because it performs the actual add/subtract operation in signed arithmetic, rather than unsigned. Patch by Francois-Xavie Coudert! llvm-svn: 221826
* builtins: avoid endian.h in favour of compiler builtinsSaleem Abdulrasool2014-10-251-4/+3
| | | | | | | Use the __BYTE_ORDER__ macro which has been available in GCC since 4.6 and is available in clang as well. llvm-svn: 220626
* Fix checks for Android.Dan Albert2014-10-201-4/+4
| | | | | | | | | | | | __ANDROID__ is a define that comes from the toolchain when building for Android targets. ANDROID has a different meaning. ANDROID is defined for _every_ Android build, including those done for host modules. For host modules, we want to build the regular Linux sanitizers and builtins, not the one for Android devices. This hasn't been a problem until now because we only just started building the sanitizers for the host. llvm-svn: 220203
* Add complex multiply/divide functions to arm64 iOS libclang_rt libraries.Bob Wilson2014-10-141-13/+0
| | | | | | | | Clang r219557 introduces libcalls to complex multiply/divide functions. Since these functions are not available in iOS for arm64 devices, add them to the static libraries. llvm-svn: 219715
* AArch64: add support for ARM64 iOS versions of compiler-rt.Tim Northover2014-10-084-1/+37
| | | | | | | | Just a dummy directory and a few sane choices in the Darwin SDK. rdar://problem/18575597 llvm-svn: 219323
* builtins: add missed change from previous commitSaleem Abdulrasool2014-10-071-1/+1
| | | | | | | The macro rework was missing a trailing SEPARATOR for the .thumb_func, resulting in assembly failures. llvm-svn: 219183
* builtins: rework use of DEFINE_COMPILERRT_THUMB_FUNCTIONSaleem Abdulrasool2014-10-0711-8/+44
| | | | | | | | | | | | | | | This is simply to help clarity of the code. The functions are built as thumb only if Thumb2 is available (__ARM_ARCH_ISA_THUMB == 2). Sink the selection into the location of the definition and make DEFINE_COMPILERRT_THUMB_FUNCTION always define a thumb function while DEFINE_COMPILERRT_FUNCTION always selects the default. Since the .thumb_func directive is always available (at least on Linux, Windows, and BSD), sinking the macro right into the macro works just as well. No functional change intended. llvm-svn: 219182
* Try harder to fix ARM/Linux after r219040.Bob Wilson2014-10-041-1/+6
| | | | llvm-svn: 219066
* Attempt to fix ARM/Linux after r219040.Bob Wilson2014-10-041-1/+1
| | | | llvm-svn: 219064
* Fix the armv7 thumb builtins on darwinSteven Wu2014-10-0412-12/+24
| | | | | | | | | | The arm builtins converted into thumb in r213481 are not working on darwin. On apple platforms, .thumb_func directive is required to generated correct symbols for thumb functions. <rdar://problem/18523605> llvm-svn: 219040
* [sanitizer] Add i686 arch to compiler-rt.Evgeniy Stepanov2014-10-011-1/+4
| | | | | | | | | | This is needed so we can produce -i686- named libraries for x86 Android (which is i686-linux-android). An alternative solution would be keeping the "i386" name internally and tweaking the OUTPUT_NAME of compiler-rt libraries. llvm-svn: 218761
* [compiler-rt] Do not use ldrexd or strexd on v7MOliver Stannard2014-09-2910-0/+20
| | | | | | | | | | | | | | | | The ldrexd and strexd instructions are undefined for the ARMv7M architecture, so we cannot use them to implement the __sync_fetch_and_*_8 builtins. There is no other way to implement these without OS support, so this patch #ifdef's these functions out for M-class architectures. There are no tests as I cannot find any existing tests for these builtins. I used the __ARM_ARCH_PROFILE predefine because __ARM_FEATURE_LDREX is deprecated and not set by clang. llvm-svn: 218601
* builtins: 80-columnSaleem Abdulrasool2014-09-191-2/+4
| | | | | | Re-wrap a couple of lines. NFC. llvm-svn: 218096
* builtins: remove definition of __ARM_ARCHSaleem Abdulrasool2014-09-191-27/+0
| | | | | | | | __ARM_ARCH is part of the ACLE specification. At least clang and GCC have supported this part of the ACLE for some time now. Let the compiler provide the proper definition for the macro rather than try to guess it. llvm-svn: 218095
* Implement floatsitf, floatunstfsi, which performJoerg Sonnenberger2014-09-162-0/+92
| | | | | | | | | | (signed/unsigned)integer to quad-precision conversion. Submitted by GuanHong Liu. Differential Revision: http://reviews.llvm.org/D2805 llvm-svn: 217901
* builtins: replace section symbol with reference to specSaleem Abdulrasool2014-09-081-1/+1
| | | | | | Removes a non-ascii character that was committed. llvm-svn: 217353
* builtins: add AEABI div0 functionsSaleem Abdulrasool2014-09-062-0/+44
| | | | | | | | | Add the missing AEABI functions that are part of the base platform ABI specification. The provided implementation does the bare minimum to avoid requiring libc headers. This permits the use of compiler-rt on bare-metal environments which conform to EABI. llvm-svn: 217322
* builtins: remove unnecessary COMPILER_RT_EXPORTSaleem Abdulrasool2014-09-062-11/+3
| | | | | | | This macro did not do anything at this point, and is not particularly needed for Windows unless building the builtins as a shared library. NFC. llvm-svn: 217321
* builtins: add signature to some assembly routinesSaleem Abdulrasool2014-08-096-0/+23
| | | | | | | Add a helpful description and a signature for the functions implemented in assembly for the integral math routines. NFC. llvm-svn: 215296
* builtins: correct __umodsi3, __udivsi3 on ARMSaleem Abdulrasool2014-08-092-7/+3
| | | | | | | | | | | | | When building the builtins for a modern CPU (idiv support), __umodsi3 was completely incorrect as it would behave as __udivmosi3, which takes a tertiary parameter which is a pointer. __udivsi3 was also incorrect, returning the remainder in r1. Although this would not result in any crash or invalid behaviour as r1 is a caller saved register in AAPCS, this is unnecessary. Simply perform the division ignoring the remainder. llvm-svn: 215295
* builtins: make ARM compilation with GAS work againSaleem Abdulrasool2014-07-274-5/+11
| | | | | | | | | | The LLVM IAS seems to accept wide instructions for add and sub in ARM mode even though it is not permitted. This uses a macro to ensure that the wide modifier is only applied when building in THUMB mode. This repairs building with GCC/GAS in ARM mode. llvm-svn: 214046
* builtins: move macro definitions into assembly.hSaleem Abdulrasool2014-07-274-24/+8
| | | | | | | The macro definitions are shared across multiple files. Define them once in the assembly.h header rather than redefining it in each file. llvm-svn: 214045
* builtins: whitespaceSaleem Abdulrasool2014-07-272-8/+8
| | | | llvm-svn: 214044
* builtins: avoid multiple definitions of symbolsSaleem Abdulrasool2014-07-261-7/+18
| | | | | | | | | | | | | | | | | | The architecture specific implementation of routines would be built and included along with the generic implementation. This would result in multiple definitions of those symbols. The linker is free to select either of the two. Most of the time, this shouldn't be too terrible as the forward iteration should catch the architecture version due to the ordering. Rather than relying on the linker and build infrastructure ordering things in a specific manner, only provide the architecture version when available. This reduces the size of compiler-rt, simplifies inspection of the library implementations, and guarantees that the desired version is selected at a slightly complex build system. llvm-svn: 214040
* builtins: add missed files from previous commitsSaleem Abdulrasool2014-07-264-3/+11
| | | | | | | This adds missed files in SVN r214033 for alignment and corrects a change from SVN r214034 for fixing compilation with GCC. llvm-svn: 214039
* builtins: move the readonly constants into rodataSaleem Abdulrasool2014-07-264-8/+27
| | | | | | | Place the floating point constants into the read-only data section. This was already being done for x86_64, this simply mirrors the behaviour for i686. llvm-svn: 214034
* builtins: correct constant alignmentsSaleem Abdulrasool2014-07-264-17/+41
| | | | | | | | | | | | | | | | | | | MMX/SSE instructions expect 128-bit alignment (16-byte) for constants that they reference. Correct the alignment on the constant values. Although it is quite possible for the data to end up aligned, there is no guarantee that this will occur unless it is explicitly aligned to the desired location. If the data ends up being unaligned, the resultant binary would fault at runtime due to the unaligned access. As an example, the follow would fault previously: cc -c lib/builtins/x86_64/floatundidf.S -o floatundidf.o cc -c test/builtins/Unit/floatundidf_test.c -o floatundidf_test.c ld -m elf_x86_64 floatundidf.o floatundidf_test.o -lc -o floatundidf However, if the object files were reversed, the data would end up aligned and the problem would go unnoticed. llvm-svn: 214033
OpenPOWER on IntegriCloud