RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-26 04:32:44 +01:00
Code Issues Projects Releases Wiki Activity
d4f3796eeb
llvm-mirror/test/CodeGen/AArch64/arm64-call-tailcalls.ll

101 lines
2.5 KiB
LLVM
Raw Normal View History

ARM64: initial backend import This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
2014-03-29 11:18:08 +01:00
; RUN: llc < %s -mtriple=arm64-apple-ios7.0 | FileCheck %s
@t = weak global i32 ()* null
@x = external global i32, align 4
define void @t2() {
; CHECK-LABEL: t2:
; CHECK: adrp x[[GOTADDR:[0-9]+]], _t@GOTPAGE
; CHECK: ldr x[[ADDR:[0-9]+]], [x[[GOTADDR]], _t@GOTPAGEOFF]
; CHECK: ldr x[[DEST:[0-9]+]], [x[[ADDR]]]
; CHECK: br x[[DEST]]
[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-27 22:17:42 +01:00
%tmp = load i32 ()*, i32 ()** @t
ARM64: initial backend import This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
2014-03-29 11:18:08 +01:00
%tmp.upgrd.2 = tail call i32 %tmp()
ret void
}
define void @t3() {
; CHECK-LABEL: t3:
; CHECK: b _t2
tail call void @t2()
ret void
}
define double @t4(double %a) nounwind readonly ssp {
; CHECK-LABEL: t4:
; CHECK: b _sin
%tmp = tail call double @sin(double %a) nounwind readonly
ret double %tmp
}
define float @t5(float %a) nounwind readonly ssp {
; CHECK-LABEL: t5:
; CHECK: b _sinf
%tmp = tail call float @sinf(float %a) nounwind readonly
ret float %tmp
}
define void @t7() nounwind {
; CHECK-LABEL: t7:
; CHECK: b _foo
; CHECK: b _bar
br i1 undef, label %bb, label %bb1.lr.ph
bb1.lr.ph: ; preds = %entry
tail call void @bar() nounwind
ret void
bb: ; preds = %entry
tail call void @foo() nounwind
ret void
}
define i32 @t8(i32 %x) nounwind ssp {
; CHECK-LABEL: t8:
Re-apply r234898 and fix tests. This commit makes LLVM not estimate branch probabilities when doing a single bit bitmask tests. The code that originally made me discover this is: if ((a & 0x1) == 0x1) { .. } In this case we don't actually have any branch probability information and should not assume to have any. LLVM transforms this into: %and = and i32 %a, 1 %tobool = icmp eq i32 %and, 0 So, in this case, the result of a bitwise and is compared against 0, but nevertheless, we should not assume to have probability information. CodeGen/ARM/2013-10-11-select-stalls.ll started failing because the changed probabilities changed the results of ARMBaseInstrInfo::isProfitableToIfCvt() and led to an Ifcvt of the diamond in the test. AFAICT, the test was never meant to test this and thus changing the test input slightly to not change the probabilities seems like the best way to preserve the meaning of the test. llvm-svn: 234979
2015-04-15 08:24:07 +02:00
; CHECK: b _c
ARM64: initial backend import This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
2014-03-29 11:18:08 +01:00
; CHECK: b _a
; CHECK: b _b
%and = and i32 %x, 1
%tobool = icmp eq i32 %and, 0
br i1 %tobool, label %if.end, label %if.then
if.then: ; preds = %entry
%call = tail call i32 @a(i32 %x) nounwind
br label %return
if.end: ; preds = %entry
%and1 = and i32 %x, 2
%tobool2 = icmp eq i32 %and1, 0
br i1 %tobool2, label %if.end5, label %if.then3
if.then3: ; preds = %if.end
%call4 = tail call i32 @b(i32 %x) nounwind
br label %return
if.end5: ; preds = %if.end
%call6 = tail call i32 @c(i32 %x) nounwind
br label %return
return: ; preds = %if.end5, %if.then3, %if.then
%retval.0 = phi i32 [ %call, %if.then ], [ %call4, %if.then3 ], [ %call6, %if.end5 ]
ret i32 %retval.0
}
declare float @sinf(float) nounwind readonly
declare double @sin(double) nounwind readonly
declare void @bar() nounwind
declare void @foo() nounwind
declare i32 @a(i32)
declare i32 @b(i32)
declare i32 @c(i32)
AArch64: Cleanup tailcall CC check, enable swiftcc. Cleanup/change the code that checks for possible tailcall conventions to look the same as the one in the X86 target. This makes the distinction between calling conventions that can guarnatee tailcalls and the ones that may tailcall more obvious. - Add Swift to the mayTailCall list - PreserveMost seemed to be incorrectly part of the guarnteed tail call list, move it to the mayTailCall list. llvm-svn: 281376
2016-09-13 21:27:38 +02:00
; CHECK-LABEL: tswift:
; CHECK: b _swiftfunc
define swiftcc i32 @tswift(i32 %a) nounwind {
%res = tail call i32 @swiftfunc(i32 %a)
ret i32 %res
}
declare swiftcc i32 @swiftfunc(i32) nounwind
Reference in New Issue Copy Permalink