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/X86/cvt16.ll

90 lines
3.0 KiB
LLVM
Raw Normal View History

[X86] Add ISel patterns to select 'f32_to_f16' and 'f16_to_f32' dag nodes. This patch adds tablegen patterns to select F16C float-to-half-float conversion instructions from 'f32_to_f16' and 'f16_to_f32' dag nodes. If the target doesn't have F16C, then 'f32_to_f16' and 'f16_to_f32' are expanded into library calls. llvm-svn: 212293
2014-07-04 05:51:06 +08:00
; RUN: llc < %s -march=x86-64 -mtriple=x86_64-unknown-linux-gnu -mcpu=corei7 -mattr=-f16c | FileCheck %s -check-prefix=CHECK -check-prefix=LIBCALL
; RUN: llc < %s -march=x86-64 -mtriple=x86_64-unknown-linux-gnu -mcpu=corei7 -mattr=+f16c | FileCheck %s -check-prefix=CHECK -check-prefix=F16C
; RUN: llc < %s -march=x86-64 -mtriple=x86_64-unknown-linux-gnu -mcpu=corei7 -soft-float=1 -mattr=-f16c | FileCheck %s -check-prefix=CHECK -check-prefix=SOFTFLOAT
; RUN: llc < %s -march=x86-64 -mtriple=x86_64-unknown-linux-gnu -mcpu=corei7 -soft-float=1 -mattr=+f16c | FileCheck %s -check-prefix=CHECK -check-prefix=SOFTFLOAT
; This is a test for float to half float conversions on x86-64.
;
; If flag -soft-float is set, or if there is no F16C support, then:
; 1) half float to float conversions are
; translated into calls to __gnu_h2f_ieee defined
; by the compiler runtime library;
; 2) float to half float conversions are translated into calls
; to __gnu_f2h_ieee which expected to be defined by the
; compiler runtime library.
;
; Otherwise (we have F16C support):
; 1) half float to float conversion are translated using
; vcvtph2ps instructions;
; 2) float to half float conversions are translated using
; vcvtps2ph instructions
define void @test1(float %src, i16* %dest) {
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
%1 = tail call i16 @llvm.convert.to.fp16.f32(float %src)
[X86] Add ISel patterns to select 'f32_to_f16' and 'f16_to_f32' dag nodes. This patch adds tablegen patterns to select F16C float-to-half-float conversion instructions from 'f32_to_f16' and 'f16_to_f32' dag nodes. If the target doesn't have F16C, then 'f32_to_f16' and 'f16_to_f32' are expanded into library calls. llvm-svn: 212293
2014-07-04 05:51:06 +08:00
store i16 %1, i16* %dest, align 2
ret void
}
; CHECK-LABEL: test1
; LIBCALL: callq __gnu_f2h_ieee
; SOFTFLOAT: callq __gnu_f2h_ieee
; F16C: vcvtps2ph
; CHECK: ret
define float @test2(i16* nocapture %src) {
%1 = load i16* %src, 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 %1)
[X86] Add ISel patterns to select 'f32_to_f16' and 'f16_to_f32' dag nodes. This patch adds tablegen patterns to select F16C float-to-half-float conversion instructions from 'f32_to_f16' and 'f16_to_f32' dag nodes. If the target doesn't have F16C, then 'f32_to_f16' and 'f16_to_f32' are expanded into library calls. llvm-svn: 212293
2014-07-04 05:51:06 +08:00
ret float %2
}
; CHECK-LABEL: test2:
; LIBCALL: jmp __gnu_h2f_ieee
; SOFTFLOAT: callq __gnu_h2f_ieee
; F16C: vcvtph2ps
; F16C: ret
define float @test3(float %src) nounwind uwtable readnone {
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
%1 = tail call i16 @llvm.convert.to.fp16.f32(float %src)
%2 = tail call float @llvm.convert.from.fp16.f32(i16 %1)
[X86] Add ISel patterns to select 'f32_to_f16' and 'f16_to_f32' dag nodes. This patch adds tablegen patterns to select F16C float-to-half-float conversion instructions from 'f32_to_f16' and 'f16_to_f32' dag nodes. If the target doesn't have F16C, then 'f32_to_f16' and 'f16_to_f32' are expanded into library calls. llvm-svn: 212293
2014-07-04 05:51:06 +08:00
ret float %2
}
; CHECK-LABEL: test3:
; LIBCALL: callq __gnu_f2h_ieee
; LIBCALL: jmp __gnu_h2f_ieee
; SOFTFLOAT: callq __gnu_f2h_ieee
; SOFTFLOAT: callq __gnu_h2f_ieee
; F16C: vcvtps2ph
; F16C-NEXT: vcvtph2ps
; F16C: ret
X86: support double extension of f16 type. x86 has no native ability to extend an f16 to f64, but the same result is obtained if we expand it into two separate extensions: f16 -> f32 -> f64. Unfortunately the same is not true for truncate, so that still results in a compilation failure. llvm-svn: 213251
2014-07-17 19:04:04 +08:00
define double @test4(i16* nocapture %src) {
%1 = load i16* %src, align 2
%2 = tail call double @llvm.convert.from.fp16.f64(i16 %1)
ret double %2
}
; CHECK-LABEL: test4:
; LIBCALL: callq __gnu_h2f_ieee
; LIBCALL: cvtss2sd
; SOFTFLOAT: callq __gnu_h2f_ieee
; SOFTFLOAT: callq __extendsfdf2
; F16C: vcvtph2ps
; F16C: vcvtss2sd
; F16C: ret
CodeGen: generate single libcall for fptrunc -> f16 operations. Previously we asserted on this code. Currently compiler-rt doesn't actually implement any of these new libcalls, but external help is pretty much the only viable option for LLVM. I've followed the much more generic "__truncST2" naming, as opposed to the odd name for f32 -> f16 truncation. This can obviously be changed later, or overridden by any targets that need to. llvm-svn: 213252
2014-07-17 19:12:12 +08:00
define i16 @test5(double %src) {
%val = tail call i16 @llvm.convert.to.fp16.f64(double %src)
ret i16 %val
}
; CHECK-LABEL: test5:
; LIBCALL: jmp __truncdfhf2
; SOFTFLOAT: callq __truncdfhf2
; F16C: jmp __truncdfhf2
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
declare i16 @llvm.convert.to.fp16.f32(float) nounwind readnone
X86: support double extension of f16 type. x86 has no native ability to extend an f16 to f64, but the same result is obtained if we expand it into two separate extensions: f16 -> f32 -> f64. Unfortunately the same is not true for truncate, so that still results in a compilation failure. llvm-svn: 213251
2014-07-17 19:04:04 +08:00
declare double @llvm.convert.from.fp16.f64(i16) nounwind readnone
CodeGen: generate single libcall for fptrunc -> f16 operations. Previously we asserted on this code. Currently compiler-rt doesn't actually implement any of these new libcalls, but external help is pretty much the only viable option for LLVM. I've followed the much more generic "__truncST2" naming, as opposed to the odd name for f32 -> f16 truncation. This can obviously be changed later, or overridden by any targets that need to. llvm-svn: 213252
2014-07-17 19:12:12 +08:00
declare i16 @llvm.convert.to.fp16.f64(double) nounwind readnone