maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/compiler-rt/lib/builtins/i386/floatundidf.S

55 lines
1.4 KiB
ArmAsm
Raw Normal View History

Update some .S file headers. llvm-svn: 85262
2009-10-28 01:49:19 +08:00
//===-- floatundidf.S - Implement __floatundidf for i386 ------------------===//
Initial import of compiler-rt. - llvm-svn: 74292
2009-06-27 00:47:03 +08:00
//
Update more file headers across all of the LLVM projects in the monorepo to reflect the new license. These used slightly different spellings that defeated my regular expressions. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351648
2019-01-19 18:56:40 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Initial import of compiler-rt. - llvm-svn: 74292
2009-06-27 00:47:03 +08:00
//
//===----------------------------------------------------------------------===//
//
// This file implements __floatundidf for the compiler_rt library.
//
//===----------------------------------------------------------------------===//
Add assembly.h for use in .S files. llvm-svn: 85263
2009-10-28 01:49:50 +08:00
#include "../assembly.h"
Initial import of compiler-rt. - llvm-svn: 74292
2009-06-27 00:47:03 +08:00
// double __floatundidf(du_int a);
#ifdef __i386__
builtins: cleanup constant data section selection 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
2014-12-10 10:36:22 +08:00
CONST_SECTION
builtins: move the readonly constants into rodata 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
2014-07-27 05:08:41 +08:00
builtins: correct constant alignments 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
2014-07-27 05:08:34 +08:00
.balign 16
twop52:
.quad 0x4330000000000000
.balign 16
Initial import of compiler-rt. - llvm-svn: 74292
2009-06-27 00:47:03 +08:00
twop84_plus_twop52:
builtins: correct constant alignments 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
2014-07-27 05:08:34 +08:00
.quad 0x4530000000100000
.balign 16
twop84:
.quad 0x4530000000000000
Initial import of compiler-rt. - llvm-svn: 74292
2009-06-27 00:47:03 +08:00
#define REL_ADDR(_a) (_a)-0b(%eax)
.text
[CompilerRT] use .p2align, .balign instead of .align The .align statements in ARM assembly routines is actually meant to be a power of 2 alignment (e.g. .align 2 == 4 byte alignment, not 2). Switch to using .p2align. .p2align is guaranteed to be a power-of-two alignment always and much more explicit. The .align in the case of x86_64 is byte alignment, use .balign instead of .align. llvm-svn: 208578
2014-05-12 23:23:37 +08:00
.balign 4
Switch to using DEFINE_COMPILERRT_[PRIVATE_]FUNCTION to define function symbols inside .S files. llvm-svn: 85264
2009-10-28 01:50:21 +08:00
DEFINE_COMPILERRT_FUNCTION(__floatundidf)
Initial import of compiler-rt. - llvm-svn: 74292
2009-06-27 00:47:03 +08:00
movss 8(%esp), %xmm1 // high 32 bits of a
movss 4(%esp), %xmm0 // low 32 bits of a
calll 0f
0: popl %eax
orpd REL_ADDR(twop84), %xmm1 // 0x1p84 + a_hi (no rounding occurs)
subsd REL_ADDR(twop84_plus_twop52), %xmm1 // a_hi - 0x1p52 (no rounding occurs)
orpd REL_ADDR(twop52), %xmm0 // 0x1p52 + a_lo (no rounding occurs)
addsd %xmm1, %xmm0 // a_hi + a_lo (round happens here)
movsd %xmm0, 4(%esp)
fldl 4(%esp)
ret
Add end-of-function markers. llvm-svn: 200006
2014-01-24 22:40:53 +08:00
END_COMPILERRT_FUNCTION(__floatundidf)
Initial import of compiler-rt. - llvm-svn: 74292
2009-06-27 00:47:03 +08:00
#endif // __i386__
builtins: tag with noexecstack These routines do not require executable stacks. However, by default ELFish linkers may assume an executable stack on GNUish environments (and some non-GNU ones too!). The GNU extension to add a note to indicate a non-executable stack is honoured by these environments to mark the stack as non-executable (the compiler normally emits this directive on appropriate targets whenever possible). This allows normal builds from getting executable stacks due to linking to the compiler rt builtins. llvm-svn: 273500
2016-06-23 06:09:42 +08:00
NO_EXEC_STACK_DIRECTIVE