llvm-project/compiler-rt/lib/builtins/arm/floatunssisfvfp.S

//===-- floatunssisfvfp.S - Implement floatunssisfvfp ---------------------===//
//
// 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
//
//===----------------------------------------------------------------------===//

#include "../assembly.h"

//
// extern float __floatunssisfvfp(unsigned int a);
//
// Converts single precision float to a 32-bit int rounding towards zero.
// Uses Darwin calling convention where a single precision result is
// return in a GPR..
//
	.syntax unified
	.p2align 2
DEFINE_COMPILERRT_FUNCTION(__floatunssisfvfp)
#if defined(COMPILER_RT_ARMHF_TARGET)
	vmov s0, r0
	vcvt.f32.u32 s0, s0
#else
	vmov	s15, r0	       // move int to float register s15
	vcvt.f32.u32 s15, s15  // convert 32-bit int in s15 to float in s15
	vmov	r0, s15        // move s15 to result register
#endif
	bx	lr
END_COMPILERRT_FUNCTION(__floatunssisfvfp)

NO_EXEC_STACK_DIRECTIVE
add conversion functions and test cases for ARM llvm-svn: 81809 2009-09-15 07:26:56 +08:00			`//===-- floatunssisfvfp.S - Implement floatunssisfvfp ---------------------===//`
			`//`
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`
add conversion functions and test cases for ARM llvm-svn: 81809 2009-09-15 07:26:56 +08:00			`//`
			`//===----------------------------------------------------------------------===//`

Add assembly.h for use in .S files. llvm-svn: 85263 2009-10-28 01:49:50 +08:00			`#include "../assembly.h"`
add conversion functions and test cases for ARM llvm-svn: 81809 2009-09-15 07:26:56 +08:00
			`//`
			`// extern float __floatunssisfvfp(unsigned int a);`
			`//`
			`// Converts single precision float to a 32-bit int rounding towards zero.`
[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 2019-04-29 06:47:49 +08:00			`// Uses Darwin calling convention where a single precision result is`
add conversion functions and test cases for ARM llvm-svn: 81809 2009-09-15 07:26:56 +08:00			`// return in a GPR..`
			`//`
Change ARM vfp assembly functions to use unified syntax. llvm-svn: 138332 2011-08-24 00:40:18 +08:00			`.syntax unified`
[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			`.p2align 2`
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(__floatunssisfvfp)`
builtins: support building ARM builtins for a HF target The `-target` impacts the CC for the builtins. HF targets (with either floating point ABI) always use AAPCS VFP for the builtins unless they are AEABI builtins, in which case they use AAPCS. Non-HF targets (with either floating point ABI) always use AAPCS for the builtins and AAPCS for the AEABI builtins. This introduces the thunks necessary to switch CC for the floating point operations. This is not currently enabled, and should be dependent on the target being used to build compiler-rt. However, as a stop-gap, a define can be added for ASFLAGS to get the thunks. llvm-svn: 291677 2017-01-12 00:19:25 +08:00			`#if defined(COMPILER_RT_ARMHF_TARGET)`
			`vmov s0, r0`
			`vcvt.f32.u32 s0, s0`
			`#else`
Change ARM vfp assembly functions to use unified syntax. llvm-svn: 138332 2011-08-24 00:40:18 +08:00			`vmov s15, r0 // move int to float register s15`
			`vcvt.f32.u32 s15, s15 // convert 32-bit int in s15 to float in s15`
			`vmov r0, s15 // move s15 to result register`
builtins: support building ARM builtins for a HF target The `-target` impacts the CC for the builtins. HF targets (with either floating point ABI) always use AAPCS VFP for the builtins unless they are AEABI builtins, in which case they use AAPCS. Non-HF targets (with either floating point ABI) always use AAPCS for the builtins and AAPCS for the AEABI builtins. This introduces the thunks necessary to switch CC for the floating point operations. This is not currently enabled, and should be dependent on the target being used to build compiler-rt. However, as a stop-gap, a define can be added for ASFLAGS to get the thunks. llvm-svn: 291677 2017-01-12 00:19:25 +08:00			`#endif`
add conversion functions and test cases for ARM llvm-svn: 81809 2009-09-15 07:26:56 +08:00			`bx lr`
Mechanically add end-of-function markers. llvm-svn: 200005 2014-01-24 22:33:42 +08:00			`END_COMPILERRT_FUNCTION(__floatunssisfvfp)`
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`