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/AArch64/tailcall-explicit-sret.ll

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

107 lines
3.5 KiB
LLVM
Raw Normal View History

[AArch64] Register passes so they can be run by llc Initialize all AArch64-specific passes in the TargetMachine so they can be run by llc. This can lead to conflicts in opt with some command line options that share the same name as the pass, so I took this opportunity to do some cleanups: * rename all relevant command line options from "aarch64-blah" to "aarch64-enable-blah" and update the tests accordingly * run clang-format on their declarations * move all these declarations to a common place (the TargetMachine) as opposed to having them scattered around (AArch64BranchRelaxation and AArch64AddressTypePromotion were the only offenders) llvm-svn: 277322
2016-08-01 13:56:57 +08:00
; RUN: llc < %s -mtriple arm64-apple-darwin -aarch64-enable-ldst-opt=false -asm-verbose=false -disable-post-ra | FileCheck %s
[CodeGen] Don't attempt a tail-call with a non-forwarded explicit sret. Tailcalls are only OK with forwarded sret pointers. With explicit sret, one approximation is to check that the pointer isn't an Instruction, as in that case it might point into some local memory (alloca). That's not OK with tailcalls. Explicit sret counterpart to r233409. Differential Revison: http://reviews.llvm.org/D8510 llvm-svn: 233410
2015-03-28 04:35:49 +08:00
; Disable the load/store optimizer to avoid having LDP/STPs and simplify checks.
target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
; Check that we don't try to tail-call with a non-forwarded sret parameter.
OpaquePtr: Bulk update tests to use typed sret
2020-11-21 03:07:11 +08:00
declare void @test_explicit_sret(i1024* sret(i1024)) #0
[CodeGen] Don't attempt a tail-call with a non-forwarded explicit sret. Tailcalls are only OK with forwarded sret pointers. With explicit sret, one approximation is to check that the pointer isn't an Instruction, as in that case it might point into some local memory (alloca). That's not OK with tailcalls. Explicit sret counterpart to r233409. Differential Revison: http://reviews.llvm.org/D8510 llvm-svn: 233410
2015-03-28 04:35:49 +08:00
; This is the only OK case, where we forward the explicit sret pointer.
; CHECK-LABEL: _test_tailcall_explicit_sret:
; CHECK-NEXT: b _test_explicit_sret
OpaquePtr: Bulk update tests to use typed sret
2020-11-21 03:07:11 +08:00
define void @test_tailcall_explicit_sret(i1024* sret(i1024) %arg) #0 {
[CodeGen] Don't attempt a tail-call with a non-forwarded explicit sret. Tailcalls are only OK with forwarded sret pointers. With explicit sret, one approximation is to check that the pointer isn't an Instruction, as in that case it might point into some local memory (alloca). That's not OK with tailcalls. Explicit sret counterpart to r233409. Differential Revison: http://reviews.llvm.org/D8510 llvm-svn: 233410
2015-03-28 04:35:49 +08:00
tail call void @test_explicit_sret(i1024* %arg)
ret void
}
; CHECK-LABEL: _test_call_explicit_sret:
; CHECK-NOT: mov x8
; CHECK: bl _test_explicit_sret
; CHECK: ret
OpaquePtr: Bulk update tests to use typed sret
2020-11-21 03:07:11 +08:00
define void @test_call_explicit_sret(i1024* sret(i1024) %arg) #0 {
[CodeGen] Don't attempt a tail-call with a non-forwarded explicit sret. Tailcalls are only OK with forwarded sret pointers. With explicit sret, one approximation is to check that the pointer isn't an Instruction, as in that case it might point into some local memory (alloca). That's not OK with tailcalls. Explicit sret counterpart to r233409. Differential Revison: http://reviews.llvm.org/D8510 llvm-svn: 233410
2015-03-28 04:35:49 +08:00
call void @test_explicit_sret(i1024* %arg)
ret void
}
; CHECK-LABEL: _test_tailcall_explicit_sret_alloca_unused:
; CHECK: mov x8, sp
; CHECK-NEXT: bl _test_explicit_sret
; CHECK: ret
define void @test_tailcall_explicit_sret_alloca_unused() #0 {
%l = alloca i1024, align 8
tail call void @test_explicit_sret(i1024* %l)
ret void
}
; CHECK-LABEL: _test_tailcall_explicit_sret_alloca_dummyusers:
[ARM][AArch64][DAG] Reenable post-legalize store merge Reenable post-legalize stores with constant merging computation and corresponding test case. * Properly truncate store merge constants * Disable merging of truncated stores floating points * Ensure merges of constant stores into a single vector are constructed from legal elements. Reviewers: eastig, efriedma Reviewed By: eastig Subscribers: spatel, rengolin, aemerson, javed.absar, kristof.beyls, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D40701 llvm-svn: 319899
2017-12-06 23:30:13 +08:00
; CHECK: ldr [[PTRLOAD1:q[0-9]+]], [x0]
AArch64: Omit callframe setup/destroy when not necessary Do not create CALLSEQ_START/CALLSEQ_END when there is no callframe to setup and the callframe size is 0. - Fixes an invalid callframe nesting for byval arguments, which would look like this before this patch (as in `big-byval.ll`): ... ADJCALLSTACKDOWN 32768, 0, ... # Setup for extfunc ... ADJCALLSTACKDOWN 0, 0, ... # setup for memcpy ... BL &memcpy ... ADJCALLSTACKUP 0, 0, ... # destroy for memcpy ... BL &extfunc ADJCALLSTACKUP 32768, 0, ... # destroy for extfunc - Saves us two instructions in the common case of zero-sized stackframes. - Remove an unnecessary scheduling barrier (hence the small unittest changes). Differential Revision: https://reviews.llvm.org/D42006 llvm-svn: 322917
2018-01-19 10:45:38 +08:00
; CHECK: str [[PTRLOAD1]], [sp]
Revert "AArch64: Omit callframe setup/destroy when not necessary" This reverts commit r322917 due to multiple performance regressions in spec2006 and spec2017. XFAILed llvm/test/CodeGen/AArch64/big-callframe.ll which initially motivated this change. llvm-svn: 323683
2018-01-30 03:56:42 +08:00
; CHECK: mov x8, sp
; CHECK-NEXT: bl _test_explicit_sret
[CodeGen] Don't attempt a tail-call with a non-forwarded explicit sret. Tailcalls are only OK with forwarded sret pointers. With explicit sret, one approximation is to check that the pointer isn't an Instruction, as in that case it might point into some local memory (alloca). That's not OK with tailcalls. Explicit sret counterpart to r233409. Differential Revison: http://reviews.llvm.org/D8510 llvm-svn: 233410
2015-03-28 04:35:49 +08:00
; CHECK: ret
define void @test_tailcall_explicit_sret_alloca_dummyusers(i1024* %ptr) #0 {
%l = alloca i1024, align 8
%r = load i1024, i1024* %ptr, align 8
store i1024 %r, i1024* %l, align 8
tail call void @test_explicit_sret(i1024* %l)
ret void
}
; This is too conservative, but doesn't really happen in practice.
; CHECK-LABEL: _test_tailcall_explicit_sret_gep:
; CHECK: add x8, x0, #128
; CHECK-NEXT: bl _test_explicit_sret
; CHECK: ret
define void @test_tailcall_explicit_sret_gep(i1024* %ptr) #0 {
%ptr2 = getelementptr i1024, i1024* %ptr, i32 1
tail call void @test_explicit_sret(i1024* %ptr2)
ret void
}
; CHECK-LABEL: _test_tailcall_explicit_sret_alloca_returned:
; CHECK: mov x[[CALLERX8NUM:[0-9]+]], x8
; CHECK: mov x8, sp
; CHECK-NEXT: bl _test_explicit_sret
[ARM][AArch64][DAG] Reenable post-legalize store merge Reenable post-legalize stores with constant merging computation and corresponding test case. * Properly truncate store merge constants * Disable merging of truncated stores floating points * Ensure merges of constant stores into a single vector are constructed from legal elements. Reviewers: eastig, efriedma Reviewed By: eastig Subscribers: spatel, rengolin, aemerson, javed.absar, kristof.beyls, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D40701 llvm-svn: 319899
2017-12-06 23:30:13 +08:00
; CHECK-NEXT: ldr [[CALLERSRET1:q[0-9]+]], [sp]
; CHECK: str [[CALLERSRET1:q[0-9]+]], [x[[CALLERX8NUM]]]
[CodeGen] Don't attempt a tail-call with a non-forwarded explicit sret. Tailcalls are only OK with forwarded sret pointers. With explicit sret, one approximation is to check that the pointer isn't an Instruction, as in that case it might point into some local memory (alloca). That's not OK with tailcalls. Explicit sret counterpart to r233409. Differential Revison: http://reviews.llvm.org/D8510 llvm-svn: 233410
2015-03-28 04:35:49 +08:00
; CHECK: ret
define i1024 @test_tailcall_explicit_sret_alloca_returned() #0 {
%l = alloca i1024, align 8
tail call void @test_explicit_sret(i1024* %l)
%r = load i1024, i1024* %l, align 8
ret i1024 %r
}
; CHECK-LABEL: _test_indirect_tailcall_explicit_sret_nosret_arg:
Revert "AArch64: Omit callframe setup/destroy when not necessary" This reverts commit r322917 due to multiple performance regressions in spec2006 and spec2017. XFAILed llvm/test/CodeGen/AArch64/big-callframe.ll which initially motivated this change. llvm-svn: 323683
2018-01-30 03:56:42 +08:00
; CHECK-DAG: mov x[[CALLERX8NUM:[0-9]+]], x8
; CHECK-DAG: mov [[FPTR:x[0-9]+]], x0
[CodeGen] Don't attempt a tail-call with a non-forwarded explicit sret. Tailcalls are only OK with forwarded sret pointers. With explicit sret, one approximation is to check that the pointer isn't an Instruction, as in that case it might point into some local memory (alloca). That's not OK with tailcalls. Explicit sret counterpart to r233409. Differential Revison: http://reviews.llvm.org/D8510 llvm-svn: 233410
2015-03-28 04:35:49 +08:00
; CHECK: mov x0, sp
Revert "AArch64: Omit callframe setup/destroy when not necessary" This reverts commit r322917 due to multiple performance regressions in spec2006 and spec2017. XFAILed llvm/test/CodeGen/AArch64/big-callframe.ll which initially motivated this change. llvm-svn: 323683
2018-01-30 03:56:42 +08:00
; CHECK-NEXT: blr [[FPTR]]
[ARM][AArch64][DAG] Reenable post-legalize store merge Reenable post-legalize stores with constant merging computation and corresponding test case. * Properly truncate store merge constants * Disable merging of truncated stores floating points * Ensure merges of constant stores into a single vector are constructed from legal elements. Reviewers: eastig, efriedma Reviewed By: eastig Subscribers: spatel, rengolin, aemerson, javed.absar, kristof.beyls, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D40701 llvm-svn: 319899
2017-12-06 23:30:13 +08:00
; CHECK: ldr [[CALLERSRET1:q[0-9]+]], [sp]
; CHECK: str [[CALLERSRET1:q[0-9]+]], [x[[CALLERX8NUM]]]
[CodeGen] Don't attempt a tail-call with a non-forwarded explicit sret. Tailcalls are only OK with forwarded sret pointers. With explicit sret, one approximation is to check that the pointer isn't an Instruction, as in that case it might point into some local memory (alloca). That's not OK with tailcalls. Explicit sret counterpart to r233409. Differential Revison: http://reviews.llvm.org/D8510 llvm-svn: 233410
2015-03-28 04:35:49 +08:00
; CHECK: ret
OpaquePtr: Bulk update tests to use typed sret
2020-11-21 03:07:11 +08:00
define void @test_indirect_tailcall_explicit_sret_nosret_arg(i1024* sret(i1024) %arg, void (i1024*)* %f) #0 {
[CodeGen] Don't attempt a tail-call with a non-forwarded explicit sret. Tailcalls are only OK with forwarded sret pointers. With explicit sret, one approximation is to check that the pointer isn't an Instruction, as in that case it might point into some local memory (alloca). That's not OK with tailcalls. Explicit sret counterpart to r233409. Differential Revison: http://reviews.llvm.org/D8510 llvm-svn: 233410
2015-03-28 04:35:49 +08:00
%l = alloca i1024, align 8
tail call void %f(i1024* %l)
%r = load i1024, i1024* %l, align 8
store i1024 %r, i1024* %arg, align 8
ret void
}
; CHECK-LABEL: _test_indirect_tailcall_explicit_sret_:
; CHECK: mov x[[CALLERX8NUM:[0-9]+]], x8
; CHECK: mov x8, sp
; CHECK-NEXT: blr x0
[ARM][AArch64][DAG] Reenable post-legalize store merge Reenable post-legalize stores with constant merging computation and corresponding test case. * Properly truncate store merge constants * Disable merging of truncated stores floating points * Ensure merges of constant stores into a single vector are constructed from legal elements. Reviewers: eastig, efriedma Reviewed By: eastig Subscribers: spatel, rengolin, aemerson, javed.absar, kristof.beyls, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D40701 llvm-svn: 319899
2017-12-06 23:30:13 +08:00
; CHECK: ldr [[CALLERSRET1:q[0-9]+]], [sp]
; CHECK: str [[CALLERSRET1:q[0-9]+]], [x[[CALLERX8NUM]]]
[CodeGen] Don't attempt a tail-call with a non-forwarded explicit sret. Tailcalls are only OK with forwarded sret pointers. With explicit sret, one approximation is to check that the pointer isn't an Instruction, as in that case it might point into some local memory (alloca). That's not OK with tailcalls. Explicit sret counterpart to r233409. Differential Revison: http://reviews.llvm.org/D8510 llvm-svn: 233410
2015-03-28 04:35:49 +08:00
; CHECK: ret
OpaquePtr: Bulk update tests to use typed sret
2020-11-21 03:07:11 +08:00
define void @test_indirect_tailcall_explicit_sret_(i1024* sret(i1024) %arg, i1024 ()* %f) #0 {
[CodeGen] Don't attempt a tail-call with a non-forwarded explicit sret. Tailcalls are only OK with forwarded sret pointers. With explicit sret, one approximation is to check that the pointer isn't an Instruction, as in that case it might point into some local memory (alloca). That's not OK with tailcalls. Explicit sret counterpart to r233409. Differential Revison: http://reviews.llvm.org/D8510 llvm-svn: 233410
2015-03-28 04:35:49 +08:00
%ret = tail call i1024 %f()
store i1024 %ret, i1024* %arg, align 8
ret void
}
attributes #0 = { nounwind }