maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/ARM/fp16.ll

106 lines
4.0 KiB
LLVM
Raw Normal View History

[ARM] Use correct half-precision functions in EABI mode The ARM RTABI defines the half- to single-precision float conversion functions with an __aeabi prefix, but libgcc only has them with a __gnu prefix. Therefore we need to emit the __aeabi version when compiling with an eabi or eabihf triple, and the __gnu version with a gnueabi or gnueabihf triple. llvm-svn: 249565
2015-10-08 00:58:49 +08:00
; RUN: llc -mtriple=armv7a--none-eabi < %s | FileCheck --check-prefix=CHECK --check-prefix=CHECK-HARDFLOAT-EABI %s
; RUN: llc -mtriple=armv7a--none-gnueabi < %s | FileCheck --check-prefix=CHECK --check-prefix=CHECK-HARDFLOAT-GNU %s
Add support for musl-libc on ARM Linux. Patch by Lei Zhang! llvm-svn: 273726
2016-06-25 05:14:33 +08:00
; RUN: llc -mtriple=armv7a--none-musleabi < %s | FileCheck --check-prefix=CHECK --check-prefix=CHECK-HARDFLOAT-GNU %s
[ARM] Use correct half-precision functions in EABI mode The ARM RTABI defines the half- to single-precision float conversion functions with an __aeabi prefix, but libgcc only has them with a __gnu prefix. Therefore we need to emit the __aeabi version when compiling with an eabi or eabihf triple, and the __gnu version with a gnueabi or gnueabihf triple. llvm-svn: 249565
2015-10-08 00:58:49 +08:00
; RUN: llc -mtriple=armv8-eabihf < %s | FileCheck --check-prefix=CHECK --check-prefix=CHECK-ARMV8 %s
; RUN: llc -mtriple=thumbv7m-eabi < %s | FileCheck --check-prefix=CHECK --check-prefix=CHECK-SOFTFLOAT-EABI %s
; RUN: llc -mtriple=thumbv7m-gnueabi < %s | FileCheck --check-prefix=CHECK --check-prefix=CHECK-SOFTFLOAT-GNU %s
Add support for musl-libc on ARM Linux. Patch by Lei Zhang! llvm-svn: 273726
2016-06-25 05:14:33 +08:00
; RUN: llc -mtriple=thumbv7m-musleabi < %s | FileCheck --check-prefix=CHECK --check-prefix=CHECK-SOFTFLOAT-GNU %s
ARM: fix @llvm.convert.from.fp16 on softfloat targets. We need to make sure we use the softened version of all appropriate operands in the libcall, or things go horribly wrong. This may entail actually executing a 1-stage softening. llvm-svn: 214175
2014-07-29 17:56:38 +08:00
[CodeGen] Don't assume fp_to_fp16 produces i16 when legalizing it. Since r230276, we support an improved legalization for f64->f16, which goes through a temporary f32, improving codegen when f32->f16 is legal but not f64->f16. This requires unsafe-fp-math. However, that legalization assumed that the second step, producing a pseudo-softened f16, had type i16. That's not true on targets with illegal i16, such as ARM. Use the initial f64->f16 result type instead. llvm-svn: 257794
2016-01-15 03:45:36 +08:00
;; +fp16 is special: it has f32->f16 (unlike v7), but not f64->f16 (unlike v8).
;; This exposes unsafe-fp-math optimization opportunities; test that.
; RUN: llc -mattr=+vfp3,+fp16 < %s |\
; RUN: FileCheck --check-prefix=CHECK --check-prefix=CHECK-FP16 --check-prefix=CHECK-FP16-SAFE %s
; RUN: llc -mattr=+vfp3,+fp16 < %s -enable-unsafe-fp-math |\
; RUN: FileCheck --check-prefix=CHECK --check-prefix=CHECK-FP16 --check-prefix=CHECK-FP16-UNSAFE %s
Feature test for half precision FP. llvm-svn: 98504
2010-03-15 02:42:43 +08:00
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-n32"
ARM: __gnu_h2f_ieee and __gnu_f2h_ieee always use the soft-float calling convention By default, LLVM uses the "C" calling convention for all runtime library functions. The half-precision FP conversion functions use the soft-float calling convention, and are needed for some targets which use the hard-float convention by default, so must have their calling convention explicitly set. llvm-svn: 215348
2014-08-11 17:12:32 +08:00
target triple = "armv7---eabihf"
Feature test for half precision FP. llvm-svn: 98504
2010-03-15 02:42:43 +08:00
@x = global i16 12902
@y = global i16 0
@z = common global i16 0
ARM: __gnu_h2f_ieee and __gnu_f2h_ieee always use the soft-float calling convention By default, LLVM uses the "C" calling convention for all runtime library functions. The half-precision FP conversion functions use the soft-float calling convention, and are needed for some targets which use the hard-float convention by default, so must have their calling convention explicitly set. llvm-svn: 215348
2014-08-11 17:12:32 +08:00
define void @foo() nounwind {
Mass update to CodeGen tests to use CHECK-LABEL for labels corresponding to function definitions for more informative error messages. No functionality change and all updated tests passed locally. This update was done with the following bash script: find test/CodeGen -name "*.ll" | \ while read NAME; do echo "$NAME" if ! grep -q "^; *RUN: *llc.*debug" $NAME; then TEMP=`mktemp -t temp` cp $NAME $TEMP sed -n "s/^define [^@]*@\([A-Za-z0-9_]*\)(.*$/\1/p" < $NAME | \ while read FUNC; do sed -i '' "s/;\(.*\)\([A-Za-z0-9_-]*\):\( *\)$FUNC: *\$/;\1\2-LABEL:\3$FUNC:/g" $TEMP done sed -i '' "s/;\(.*\)-LABEL-LABEL:/;\1-LABEL:/" $TEMP sed -i '' "s/;\(.*\)-NEXT-LABEL:/;\1-NEXT:/" $TEMP sed -i '' "s/;\(.*\)-NOT-LABEL:/;\1-NOT:/" $TEMP sed -i '' "s/;\(.*\)-DAG-LABEL:/;\1-DAG:/" $TEMP mv $TEMP $NAME fi done llvm-svn: 186280
2013-07-14 14:24:09 +08:00
; CHECK-LABEL: foo:
Feature test for half precision FP. llvm-svn: 98504
2010-03-15 02:42:43 +08:00
entry:
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%0 = load i16, i16* @x, align 2
%1 = load i16, i16* @y, align 2
CodeGen: extend f16 conversions to permit types > float. This makes the two intrinsics @llvm.convert.from.f16 and @llvm.convert.to.f16 accept types other than simple "float". This is only strictly needed for the truncate operation, since otherwise double rounding occurs and there's no way to represent the strict IEEE conversion. However, for symmetry we allow larger types in the extend too. During legalization, we can expand an "fp16_to_double" operation into two extends for convenience, but abort when the truncate isn't legal. A new libcall is probably needed here. Even after this commit, various target tweaks are needed to actually use the extended intrinsics. I've put these into separate commits for clarity, so there are no actual tests of f64 conversion here. llvm-svn: 213248
2014-07-17 18:51:23 +08:00
%2 = tail call float @llvm.convert.from.fp16.f32(i16 %0)
[ARM] Use correct half-precision functions in EABI mode The ARM RTABI defines the half- to single-precision float conversion functions with an __aeabi prefix, but libgcc only has them with a __gnu prefix. Therefore we need to emit the __aeabi version when compiling with an eabi or eabihf triple, and the __gnu version with a gnueabi or gnueabihf triple. llvm-svn: 249565
2015-10-08 00:58:49 +08:00
; CHECK-HARDFLOAT-EABI: __aeabi_h2f
; CHECK-HARDFLOAT-GNU: __gnu_h2f_ieee
The names of VFP variants of half-to-float conversion instructions were reversed. This leads to wrong codegen for float-to-half conversion intrinsics which are used to support storage-only fp16 type. NEON variants of same instructions are fine. llvm-svn: 161907
2012-08-15 07:36:01 +08:00
; CHECK-FP16: vcvtb.f32.f16
ARM: support direct f16 <-> f64 conversions ARMv8 has instructions to handle it, otherwise a libcall is needed. llvm-svn: 213254
2014-07-17 19:27:04 +08:00
; CHECK-ARMv8: vcvtb.f32.f16
[ARM] Use correct half-precision functions in EABI mode The ARM RTABI defines the half- to single-precision float conversion functions with an __aeabi prefix, but libgcc only has them with a __gnu prefix. Therefore we need to emit the __aeabi version when compiling with an eabi or eabihf triple, and the __gnu version with a gnueabi or gnueabihf triple. llvm-svn: 249565
2015-10-08 00:58:49 +08:00
; CHECK-SOFTFLOAT-EABI: __aeabi_h2f
; CHECK-SOFTFLOAT-GNU: __gnu_h2f_ieee
CodeGen: extend f16 conversions to permit types > float. This makes the two intrinsics @llvm.convert.from.f16 and @llvm.convert.to.f16 accept types other than simple "float". This is only strictly needed for the truncate operation, since otherwise double rounding occurs and there's no way to represent the strict IEEE conversion. However, for symmetry we allow larger types in the extend too. During legalization, we can expand an "fp16_to_double" operation into two extends for convenience, but abort when the truncate isn't legal. A new libcall is probably needed here. Even after this commit, various target tweaks are needed to actually use the extended intrinsics. I've put these into separate commits for clarity, so there are no actual tests of f64 conversion here. llvm-svn: 213248
2014-07-17 18:51:23 +08:00
%3 = tail call float @llvm.convert.from.fp16.f32(i16 %1)
[ARM] Use correct half-precision functions in EABI mode The ARM RTABI defines the half- to single-precision float conversion functions with an __aeabi prefix, but libgcc only has them with a __gnu prefix. Therefore we need to emit the __aeabi version when compiling with an eabi or eabihf triple, and the __gnu version with a gnueabi or gnueabihf triple. llvm-svn: 249565
2015-10-08 00:58:49 +08:00
; CHECK-HARDFLOAT-EABI: __aeabi_h2f
; CHECK-HARDFLOAT-GNU: __gnu_h2f_ieee
The names of VFP variants of half-to-float conversion instructions were reversed. This leads to wrong codegen for float-to-half conversion intrinsics which are used to support storage-only fp16 type. NEON variants of same instructions are fine. llvm-svn: 161907
2012-08-15 07:36:01 +08:00
; CHECK-FP16: vcvtb.f32.f16
ARM: support direct f16 <-> f64 conversions ARMv8 has instructions to handle it, otherwise a libcall is needed. llvm-svn: 213254
2014-07-17 19:27:04 +08:00
; CHECK-ARMV8: vcvtb.f32.f16
[ARM] Use correct half-precision functions in EABI mode The ARM RTABI defines the half- to single-precision float conversion functions with an __aeabi prefix, but libgcc only has them with a __gnu prefix. Therefore we need to emit the __aeabi version when compiling with an eabi or eabihf triple, and the __gnu version with a gnueabi or gnueabihf triple. llvm-svn: 249565
2015-10-08 00:58:49 +08:00
; CHECK-SOFTFLOAT-EABI: __aeabi_h2f
; CHECK-SOFTFLOAT-GNU: __gnu_h2f_ieee
Feature test for half precision FP. llvm-svn: 98504
2010-03-15 02:42:43 +08:00
%4 = fadd float %2, %3
CodeGen: extend f16 conversions to permit types > float. This makes the two intrinsics @llvm.convert.from.f16 and @llvm.convert.to.f16 accept types other than simple "float". This is only strictly needed for the truncate operation, since otherwise double rounding occurs and there's no way to represent the strict IEEE conversion. However, for symmetry we allow larger types in the extend too. During legalization, we can expand an "fp16_to_double" operation into two extends for convenience, but abort when the truncate isn't legal. A new libcall is probably needed here. Even after this commit, various target tweaks are needed to actually use the extended intrinsics. I've put these into separate commits for clarity, so there are no actual tests of f64 conversion here. llvm-svn: 213248
2014-07-17 18:51:23 +08:00
%5 = tail call i16 @llvm.convert.to.fp16.f32(float %4)
[ARM] Use correct half-precision functions in EABI mode The ARM RTABI defines the half- to single-precision float conversion functions with an __aeabi prefix, but libgcc only has them with a __gnu prefix. Therefore we need to emit the __aeabi version when compiling with an eabi or eabihf triple, and the __gnu version with a gnueabi or gnueabihf triple. llvm-svn: 249565
2015-10-08 00:58:49 +08:00
; CHECK-HARDFLOAT-EABI: __aeabi_f2h
; CHECK-HARDFLOAT-GNU: __gnu_f2h_ieee
The names of VFP variants of half-to-float conversion instructions were reversed. This leads to wrong codegen for float-to-half conversion intrinsics which are used to support storage-only fp16 type. NEON variants of same instructions are fine. llvm-svn: 161907
2012-08-15 07:36:01 +08:00
; CHECK-FP16: vcvtb.f16.f32
ARM: support direct f16 <-> f64 conversions ARMv8 has instructions to handle it, otherwise a libcall is needed. llvm-svn: 213254
2014-07-17 19:27:04 +08:00
; CHECK-ARMV8: vcvtb.f16.f32
[ARM] Use correct half-precision functions in EABI mode The ARM RTABI defines the half- to single-precision float conversion functions with an __aeabi prefix, but libgcc only has them with a __gnu prefix. Therefore we need to emit the __aeabi version when compiling with an eabi or eabihf triple, and the __gnu version with a gnueabi or gnueabihf triple. llvm-svn: 249565
2015-10-08 00:58:49 +08:00
; CHECK-SOFTFLOAT-EABI: __aeabi_f2h
; CHECK-SOFTFLOAT-GNU: __gnu_f2h_ieee
Feature test for half precision FP. llvm-svn: 98504
2010-03-15 02:42:43 +08:00
store i16 %5, i16* @x, align 2
ret void
}
ARM: __gnu_h2f_ieee and __gnu_f2h_ieee always use the soft-float calling convention By default, LLVM uses the "C" calling convention for all runtime library functions. The half-precision FP conversion functions use the soft-float calling convention, and are needed for some targets which use the hard-float convention by default, so must have their calling convention explicitly set. llvm-svn: 215348
2014-08-11 17:12:32 +08:00
define double @test_from_fp16(i16 %in) {
ARM: support direct f16 <-> f64 conversions ARMv8 has instructions to handle it, otherwise a libcall is needed. llvm-svn: 213254
2014-07-17 19:27:04 +08:00
; CHECK-LABEL: test_from_fp16:
%val = call double @llvm.convert.from.fp16.f64(i16 %in)
[ARM] Use correct half-precision functions in EABI mode The ARM RTABI defines the half- to single-precision float conversion functions with an __aeabi prefix, but libgcc only has them with a __gnu prefix. Therefore we need to emit the __aeabi version when compiling with an eabi or eabihf triple, and the __gnu version with a gnueabi or gnueabihf triple. llvm-svn: 249565
2015-10-08 00:58:49 +08:00
; CHECK-HARDFLOAT-EABI: bl __aeabi_h2f
; CHECK-HARDFLOAT-EABI: vmov [[TMP:s[0-9]+]], r0
; CHECK-HARDFLOAT-EABI: vcvt.f64.f32 {{d[0-9]+}}, [[TMP]]
; CHECK-HARDFLOAT-GNU: bl __gnu_h2f_ieee
; CHECK-HARDFLOAT-GNU: vmov [[TMP:s[0-9]+]], r0
; CHECK-HARDFLOAT-GNU: vcvt.f64.f32 {{d[0-9]+}}, [[TMP]]
ARM: support direct f16 <-> f64 conversions ARMv8 has instructions to handle it, otherwise a libcall is needed. llvm-svn: 213254
2014-07-17 19:27:04 +08:00
; CHECK-FP16: vmov [[TMP16:s[0-9]+]], r0
; CHECK-FP16: vcvtb.f32.f16 [[TMP32:s[0-9]+]], [[TMP16]]
; CHECK-FP16: vcvt.f64.f32 d0, [[TMP32]]
; CHECK-ARMV8: vmov [[TMP:s[0-9]+]], r0
; CHECK-ARMV8: vcvtb.f64.f16 d0, [[TMP]]
ARM: fix @llvm.convert.from.fp16 on softfloat targets. We need to make sure we use the softened version of all appropriate operands in the libcall, or things go horribly wrong. This may entail actually executing a 1-stage softening. llvm-svn: 214175
2014-07-29 17:56:38 +08:00
[ARM] Use correct half-precision functions in EABI mode The ARM RTABI defines the half- to single-precision float conversion functions with an __aeabi prefix, but libgcc only has them with a __gnu prefix. Therefore we need to emit the __aeabi version when compiling with an eabi or eabihf triple, and the __gnu version with a gnueabi or gnueabihf triple. llvm-svn: 249565
2015-10-08 00:58:49 +08:00
; CHECK-SOFTFLOAT-EABI: bl __aeabi_h2f
; CHECK-SOFTFLOAT-EABI: bl __aeabi_f2d
; CHECK-SOFTFLOAT-GNU: bl __gnu_h2f_ieee
; CHECK-SOFTFLOAT-GNU: bl __aeabi_f2d
ARM: support direct f16 <-> f64 conversions ARMv8 has instructions to handle it, otherwise a libcall is needed. llvm-svn: 213254
2014-07-17 19:27:04 +08:00
ret double %val
}
ARM: __gnu_h2f_ieee and __gnu_f2h_ieee always use the soft-float calling convention By default, LLVM uses the "C" calling convention for all runtime library functions. The half-precision FP conversion functions use the soft-float calling convention, and are needed for some targets which use the hard-float convention by default, so must have their calling convention explicitly set. llvm-svn: 215348
2014-08-11 17:12:32 +08:00
define i16 @test_to_fp16(double %in) {
ARM: support direct f16 <-> f64 conversions ARMv8 has instructions to handle it, otherwise a libcall is needed. llvm-svn: 213254
2014-07-17 19:27:04 +08:00
; CHECK-LABEL: test_to_fp16:
%val = call i16 @llvm.convert.to.fp16.f64(double %in)
[ARM] Use correct half-precision functions in EABI mode The ARM RTABI defines the half- to single-precision float conversion functions with an __aeabi prefix, but libgcc only has them with a __gnu prefix. Therefore we need to emit the __aeabi version when compiling with an eabi or eabihf triple, and the __gnu version with a gnueabi or gnueabihf triple. llvm-svn: 249565
2015-10-08 00:58:49 +08:00
; CHECK-HARDFLOAT-EABI: bl __aeabi_d2h
; CHECK-HARDFLOAT-GNU: bl __aeabi_d2h
ARM: support direct f16 <-> f64 conversions ARMv8 has instructions to handle it, otherwise a libcall is needed. llvm-svn: 213254
2014-07-17 19:27:04 +08:00
[CodeGen] Don't assume fp_to_fp16 produces i16 when legalizing it. Since r230276, we support an improved legalization for f64->f16, which goes through a temporary f32, improving codegen when f32->f16 is legal but not f64->f16. This requires unsafe-fp-math. However, that legalization assumed that the second step, producing a pseudo-softened f16, had type i16. That's not true on targets with illegal i16, such as ARM. Use the initial f64->f16 result type instead. llvm-svn: 257794
2016-01-15 03:45:36 +08:00
; CHECK-FP16-SAFE: bl __aeabi_d2h
; CHECK-FP16-UNSAFE: vcvt.f32.f64 s0, d0
; CHECK-FP16-UNSAFE-NEXT: vcvtb.f16.f32 s0, s0
ARM: support direct f16 <-> f64 conversions ARMv8 has instructions to handle it, otherwise a libcall is needed. llvm-svn: 213254
2014-07-17 19:27:04 +08:00
; CHECK-ARMV8: vcvtb.f16.f64 [[TMP:s[0-9]+]], d0
; CHECK-ARMV8: vmov r0, [[TMP]]
ARM: fix @llvm.convert.from.fp16 on softfloat targets. We need to make sure we use the softened version of all appropriate operands in the libcall, or things go horribly wrong. This may entail actually executing a 1-stage softening. llvm-svn: 214175
2014-07-29 17:56:38 +08:00
[ARM] Use correct half-precision functions in EABI mode The ARM RTABI defines the half- to single-precision float conversion functions with an __aeabi prefix, but libgcc only has them with a __gnu prefix. Therefore we need to emit the __aeabi version when compiling with an eabi or eabihf triple, and the __gnu version with a gnueabi or gnueabihf triple. llvm-svn: 249565
2015-10-08 00:58:49 +08:00
; CHECK-SOFTFLOAT-EABI: bl __aeabi_d2h
; CHECK-SOFTFLOAT-GNU: bl __aeabi_d2h
ARM: support direct f16 <-> f64 conversions ARMv8 has instructions to handle it, otherwise a libcall is needed. llvm-svn: 213254
2014-07-17 19:27:04 +08:00
ret i16 %val
}
CodeGen: extend f16 conversions to permit types > float. This makes the two intrinsics @llvm.convert.from.f16 and @llvm.convert.to.f16 accept types other than simple "float". This is only strictly needed for the truncate operation, since otherwise double rounding occurs and there's no way to represent the strict IEEE conversion. However, for symmetry we allow larger types in the extend too. During legalization, we can expand an "fp16_to_double" operation into two extends for convenience, but abort when the truncate isn't legal. A new libcall is probably needed here. Even after this commit, various target tweaks are needed to actually use the extended intrinsics. I've put these into separate commits for clarity, so there are no actual tests of f64 conversion here. llvm-svn: 213248
2014-07-17 18:51:23 +08:00
declare float @llvm.convert.from.fp16.f32(i16) nounwind readnone
ARM: support direct f16 <-> f64 conversions ARMv8 has instructions to handle it, otherwise a libcall is needed. llvm-svn: 213254
2014-07-17 19:27:04 +08:00
declare double @llvm.convert.from.fp16.f64(i16) nounwind readnone
Feature test for half precision FP. llvm-svn: 98504
2010-03-15 02:42:43 +08:00
CodeGen: extend f16 conversions to permit types > float. This makes the two intrinsics @llvm.convert.from.f16 and @llvm.convert.to.f16 accept types other than simple "float". This is only strictly needed for the truncate operation, since otherwise double rounding occurs and there's no way to represent the strict IEEE conversion. However, for symmetry we allow larger types in the extend too. During legalization, we can expand an "fp16_to_double" operation into two extends for convenience, but abort when the truncate isn't legal. A new libcall is probably needed here. Even after this commit, various target tweaks are needed to actually use the extended intrinsics. I've put these into separate commits for clarity, so there are no actual tests of f64 conversion here. llvm-svn: 213248
2014-07-17 18:51:23 +08:00
declare i16 @llvm.convert.to.fp16.f32(float) nounwind readnone
ARM: support direct f16 <-> f64 conversions ARMv8 has instructions to handle it, otherwise a libcall is needed. llvm-svn: 213254
2014-07-17 19:27:04 +08:00
declare i16 @llvm.convert.to.fp16.f64(double) nounwind readnone