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/darwin-eabi.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

25 lines
839 B
LLVM
Raw Normal View History

ARM: Tweak usage of '*vfp' compiler_rt functions. Only use them if the subtarget has ARM mode, as these routines are implemented as ARM code. rdar://15302004 llvm-svn: 193381
2013-10-25 07:07:11 +08:00
; RUN: llc -mtriple=thumbv7m-apple-darwin -mcpu=cortex-m3 < %s | FileCheck %s --check-prefix=CHECK-M3
; RUN: llc -mtriple=thumbv7em-apple-darwin -mcpu=cortex-m4 < %s | FileCheck %s --check-prefix=CHECK-M4
ARM: Test r193381 a bit more thoroughly. Make sure we're predicating right based on CPU even if the triple is 'wrong'. llvm-svn: 193382
2013-10-25 07:11:05 +08:00
; RUN: llc -mtriple=thumbv7-apple-darwin -mcpu=cortex-m3 < %s | FileCheck %s --check-prefix=CHECK-M3
; RUN: llc -mtriple=thumbv7-apple-darwin -mcpu=cortex-m4 < %s | FileCheck %s --check-prefix=CHECK-M4
ARM: Use non-VFP softcalls on embedded Darwinish targets The compiler-rt functions __adddf3vfp and so on exist purely to allow Thumb1 code to make use of VFP instructions by switching back to ARM mode, they make no sense for M-class processors which don't even have an ARM mode. Given that justification, in practice this is a platform ABI decision so the actual check is based on that rather than CPU features. rdar://problem/15302004 llvm-svn: 193327
2013-10-24 18:37:09 +08:00
define float @float_op(float %lhs, float %rhs) {
%sum = fadd float %lhs, %rhs
ret float %sum
; CHECK-M3-LABEL: float_op:
ARM: do not generate BLX instructions on Cortex-M CPUs. Particularly on MachO, we were generating "blx _dest" instructions on M-class CPUs, which don't actually exist. They happen to get fixed up by the linker into valid "bl _dest" instructions (which is why such a massive issue has remained largely undetected), but we shouldn't rely on that. llvm-svn: 214959
2014-08-06 19:13:14 +08:00
; CHECK-M3: bl ___addsf3
ARM: Use non-VFP softcalls on embedded Darwinish targets The compiler-rt functions __adddf3vfp and so on exist purely to allow Thumb1 code to make use of VFP instructions by switching back to ARM mode, they make no sense for M-class processors which don't even have an ARM mode. Given that justification, in practice this is a platform ABI decision so the actual check is based on that rather than CPU features. rdar://problem/15302004 llvm-svn: 193327
2013-10-24 18:37:09 +08:00
; CHECK-M4-LABEL: float_op:
; CHECK-M4: vadd.f32
}
define double @double_op(double %lhs, double %rhs) {
%sum = fadd double %lhs, %rhs
ret double %sum
; CHECK-M3-LABEL: double_op:
ARM: do not generate BLX instructions on Cortex-M CPUs. Particularly on MachO, we were generating "blx _dest" instructions on M-class CPUs, which don't actually exist. They happen to get fixed up by the linker into valid "bl _dest" instructions (which is why such a massive issue has remained largely undetected), but we shouldn't rely on that. llvm-svn: 214959
2014-08-06 19:13:14 +08:00
; CHECK-M3: bl ___adddf3
ARM: Use non-VFP softcalls on embedded Darwinish targets The compiler-rt functions __adddf3vfp and so on exist purely to allow Thumb1 code to make use of VFP instructions by switching back to ARM mode, they make no sense for M-class processors which don't even have an ARM mode. Given that justification, in practice this is a platform ABI decision so the actual check is based on that rather than CPU features. rdar://problem/15302004 llvm-svn: 193327
2013-10-24 18:37:09 +08:00
; CHECK-M4-LABEL: double_op:
ARM: switch armv7em MachO triple to hard-float defaults and libcalls. We were emitting incorrect calls to libm functions that LLVM had decided it knew about because the default is soft-float. Recommitted without breaking ELF this time. llvm-svn: 337450
2018-07-19 20:44:51 +08:00
; CHECK-M4: {{(bl|blx|b.w)}} ___adddf3
ARM: Use non-VFP softcalls on embedded Darwinish targets The compiler-rt functions __adddf3vfp and so on exist purely to allow Thumb1 code to make use of VFP instructions by switching back to ARM mode, they make no sense for M-class processors which don't even have an ARM mode. Given that justification, in practice this is a platform ABI decision so the actual check is based on that rather than CPU features. rdar://problem/15302004 llvm-svn: 193327
2013-10-24 18:37:09 +08:00
}