6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-21 16:31:16 +00:00
Code Issues Projects Releases Wiki Activity
5737d3f433
llvm-6502/test/Transforms/ObjCARC/retain-block-escape-analysis.ll

216 lines
7.8 KiB
LLVM
Raw Normal View History

The promised test case for r175939. This test makes sure that the ObjCARC escape analysis looks at the uses of instructions which copy the block pointer value by checking all four cases where that can occur. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177232 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-17 08:42:58 +00:00
; RUN: opt -S -objc-arc < %s | FileCheck %s
declare i8* @objc_retain(i8*) nonlazybind
declare void @objc_release(i8*) nonlazybind
declare i8* @objc_retainBlock(i8*)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Use by an instruction which copies the value is an escape if the ;
; result is an escape. The current instructions with this property are: ;
; ;
; 1. BitCast. ;
; 2. GEP. ;
; 3. PhiNode. ;
; 4. SelectInst. ;
; ;
; Make sure that such instructions do not confuse the optimizer into removing ;
; an objc_retainBlock that is needed. ;
; ;
; rdar://13273675. (With extra test cases to handle bitcast, phi, and select. ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
define void @bitcasttest(i8* %storage, void (...)* %block) {
; CHECK: define void @bitcasttest
Properly model precise lifetime when given an incomplete dataflow sequence. The normal dataflow sequence in the ARC optimizer consists of the following states: Retain -> CanRelease -> Use -> Release The optimizer before this patch stored the uses that determine the lifetime of the retainable object pointer when it bottom up hits a retain or when top down it hits a release. This is correct for an imprecise lifetime scenario since what we are trying to do is remove retains/releases while making sure that no ``CanRelease'' (which is usually a call) deallocates the given pointer before we get to the ``Use'' (since that would cause a segfault). If we are considering the precise lifetime scenario though, this is not correct. In such a situation, we *DO* care about the previous sequence, but additionally, we wish to track the uses resulting from the following incomplete sequences: Retain -> CanRelease -> Release (TopDown) Retain <- Use <- Release (BottomUp) *NOTE* This patch looks large but the most of it consists of updating test cases. Additionally this fix exposed an additional bug. I removed the test case that expressed said bug and will recommit it with the fix in a little bit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178921 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-05 22:54:28 +00:00
entry:
%t1 = bitcast void (...)* %block to i8*
; CHECK: tail call i8* @objc_retain
%t2 = tail call i8* @objc_retain(i8* %t1)
; CHECK: tail call i8* @objc_retainBlock
%t3 = tail call i8* @objc_retainBlock(i8* %t1), !clang.arc.copy_on_escape !0
%t4 = bitcast i8* %storage to void (...)**
%t5 = bitcast i8* %t3 to void (...)*
store void (...)* %t5, void (...)** %t4, align 8
; CHECK: call void @objc_release
call void @objc_release(i8* %t1)
ret void
; CHECK: }
}
define void @bitcasttest_a(i8* %storage, void (...)* %block) {
; CHECK: define void @bitcasttest_a
The promised test case for r175939. This test makes sure that the ObjCARC escape analysis looks at the uses of instructions which copy the block pointer value by checking all four cases where that can occur. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177232 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-17 08:42:58 +00:00
entry:
%t1 = bitcast void (...)* %block to i8*
; CHECK-NOT: tail call i8* @objc_retain
%t2 = tail call i8* @objc_retain(i8* %t1)
; CHECK: tail call i8* @objc_retainBlock
%t3 = tail call i8* @objc_retainBlock(i8* %t1), !clang.arc.copy_on_escape !0
%t4 = bitcast i8* %storage to void (...)**
%t5 = bitcast i8* %t3 to void (...)*
store void (...)* %t5, void (...)** %t4, align 8
; CHECK-NOT: call void @objc_release
Properly model precise lifetime when given an incomplete dataflow sequence. The normal dataflow sequence in the ARC optimizer consists of the following states: Retain -> CanRelease -> Use -> Release The optimizer before this patch stored the uses that determine the lifetime of the retainable object pointer when it bottom up hits a retain or when top down it hits a release. This is correct for an imprecise lifetime scenario since what we are trying to do is remove retains/releases while making sure that no ``CanRelease'' (which is usually a call) deallocates the given pointer before we get to the ``Use'' (since that would cause a segfault). If we are considering the precise lifetime scenario though, this is not correct. In such a situation, we *DO* care about the previous sequence, but additionally, we wish to track the uses resulting from the following incomplete sequences: Retain -> CanRelease -> Release (TopDown) Retain <- Use <- Release (BottomUp) *NOTE* This patch looks large but the most of it consists of updating test cases. Additionally this fix exposed an additional bug. I removed the test case that expressed said bug and will recommit it with the fix in a little bit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178921 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-05 22:54:28 +00:00
call void @objc_release(i8* %t1), !clang.imprecise_release !0
The promised test case for r175939. This test makes sure that the ObjCARC escape analysis looks at the uses of instructions which copy the block pointer value by checking all four cases where that can occur. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177232 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-17 08:42:58 +00:00
ret void
Properly model precise lifetime when given an incomplete dataflow sequence. The normal dataflow sequence in the ARC optimizer consists of the following states: Retain -> CanRelease -> Use -> Release The optimizer before this patch stored the uses that determine the lifetime of the retainable object pointer when it bottom up hits a retain or when top down it hits a release. This is correct for an imprecise lifetime scenario since what we are trying to do is remove retains/releases while making sure that no ``CanRelease'' (which is usually a call) deallocates the given pointer before we get to the ``Use'' (since that would cause a segfault). If we are considering the precise lifetime scenario though, this is not correct. In such a situation, we *DO* care about the previous sequence, but additionally, we wish to track the uses resulting from the following incomplete sequences: Retain -> CanRelease -> Release (TopDown) Retain <- Use <- Release (BottomUp) *NOTE* This patch looks large but the most of it consists of updating test cases. Additionally this fix exposed an additional bug. I removed the test case that expressed said bug and will recommit it with the fix in a little bit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178921 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-05 22:54:28 +00:00
; CHECK: }
The promised test case for r175939. This test makes sure that the ObjCARC escape analysis looks at the uses of instructions which copy the block pointer value by checking all four cases where that can occur. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177232 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-17 08:42:58 +00:00
}
define void @geptest(void (...)** %storage_array, void (...)* %block) {
; CHECK: define void @geptest
Properly model precise lifetime when given an incomplete dataflow sequence. The normal dataflow sequence in the ARC optimizer consists of the following states: Retain -> CanRelease -> Use -> Release The optimizer before this patch stored the uses that determine the lifetime of the retainable object pointer when it bottom up hits a retain or when top down it hits a release. This is correct for an imprecise lifetime scenario since what we are trying to do is remove retains/releases while making sure that no ``CanRelease'' (which is usually a call) deallocates the given pointer before we get to the ``Use'' (since that would cause a segfault). If we are considering the precise lifetime scenario though, this is not correct. In such a situation, we *DO* care about the previous sequence, but additionally, we wish to track the uses resulting from the following incomplete sequences: Retain -> CanRelease -> Release (TopDown) Retain <- Use <- Release (BottomUp) *NOTE* This patch looks large but the most of it consists of updating test cases. Additionally this fix exposed an additional bug. I removed the test case that expressed said bug and will recommit it with the fix in a little bit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178921 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-05 22:54:28 +00:00
entry:
%t1 = bitcast void (...)* %block to i8*
; CHECK: tail call i8* @objc_retain
%t2 = tail call i8* @objc_retain(i8* %t1)
; CHECK: tail call i8* @objc_retainBlock
%t3 = tail call i8* @objc_retainBlock(i8* %t1), !clang.arc.copy_on_escape !0
%t4 = bitcast i8* %t3 to void (...)*
%storage = getelementptr inbounds void (...)** %storage_array, i64 0
store void (...)* %t4, void (...)** %storage, align 8
; CHECK: call void @objc_release
call void @objc_release(i8* %t1)
ret void
; CHECK: }
}
define void @geptest_a(void (...)** %storage_array, void (...)* %block) {
; CHECK: define void @geptest_a
The promised test case for r175939. This test makes sure that the ObjCARC escape analysis looks at the uses of instructions which copy the block pointer value by checking all four cases where that can occur. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177232 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-17 08:42:58 +00:00
entry:
%t1 = bitcast void (...)* %block to i8*
; CHECK-NOT: tail call i8* @objc_retain
%t2 = tail call i8* @objc_retain(i8* %t1)
; CHECK: tail call i8* @objc_retainBlock
%t3 = tail call i8* @objc_retainBlock(i8* %t1), !clang.arc.copy_on_escape !0
%t4 = bitcast i8* %t3 to void (...)*
%storage = getelementptr inbounds void (...)** %storage_array, i64 0
store void (...)* %t4, void (...)** %storage, align 8
; CHECK-NOT: call void @objc_release
Properly model precise lifetime when given an incomplete dataflow sequence. The normal dataflow sequence in the ARC optimizer consists of the following states: Retain -> CanRelease -> Use -> Release The optimizer before this patch stored the uses that determine the lifetime of the retainable object pointer when it bottom up hits a retain or when top down it hits a release. This is correct for an imprecise lifetime scenario since what we are trying to do is remove retains/releases while making sure that no ``CanRelease'' (which is usually a call) deallocates the given pointer before we get to the ``Use'' (since that would cause a segfault). If we are considering the precise lifetime scenario though, this is not correct. In such a situation, we *DO* care about the previous sequence, but additionally, we wish to track the uses resulting from the following incomplete sequences: Retain -> CanRelease -> Release (TopDown) Retain <- Use <- Release (BottomUp) *NOTE* This patch looks large but the most of it consists of updating test cases. Additionally this fix exposed an additional bug. I removed the test case that expressed said bug and will recommit it with the fix in a little bit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178921 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-05 22:54:28 +00:00
call void @objc_release(i8* %t1), !clang.imprecise_release !0
The promised test case for r175939. This test makes sure that the ObjCARC escape analysis looks at the uses of instructions which copy the block pointer value by checking all four cases where that can occur. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177232 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-17 08:42:58 +00:00
ret void
Properly model precise lifetime when given an incomplete dataflow sequence. The normal dataflow sequence in the ARC optimizer consists of the following states: Retain -> CanRelease -> Use -> Release The optimizer before this patch stored the uses that determine the lifetime of the retainable object pointer when it bottom up hits a retain or when top down it hits a release. This is correct for an imprecise lifetime scenario since what we are trying to do is remove retains/releases while making sure that no ``CanRelease'' (which is usually a call) deallocates the given pointer before we get to the ``Use'' (since that would cause a segfault). If we are considering the precise lifetime scenario though, this is not correct. In such a situation, we *DO* care about the previous sequence, but additionally, we wish to track the uses resulting from the following incomplete sequences: Retain -> CanRelease -> Release (TopDown) Retain <- Use <- Release (BottomUp) *NOTE* This patch looks large but the most of it consists of updating test cases. Additionally this fix exposed an additional bug. I removed the test case that expressed said bug and will recommit it with the fix in a little bit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178921 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-05 22:54:28 +00:00
; CHECK: }
The promised test case for r175939. This test makes sure that the ObjCARC escape analysis looks at the uses of instructions which copy the block pointer value by checking all four cases where that can occur. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177232 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-17 08:42:58 +00:00
}
define void @selecttest(void (...)** %store1, void (...)** %store2,
void (...)* %block) {
; CHECK: define void @selecttest
Properly model precise lifetime when given an incomplete dataflow sequence. The normal dataflow sequence in the ARC optimizer consists of the following states: Retain -> CanRelease -> Use -> Release The optimizer before this patch stored the uses that determine the lifetime of the retainable object pointer when it bottom up hits a retain or when top down it hits a release. This is correct for an imprecise lifetime scenario since what we are trying to do is remove retains/releases while making sure that no ``CanRelease'' (which is usually a call) deallocates the given pointer before we get to the ``Use'' (since that would cause a segfault). If we are considering the precise lifetime scenario though, this is not correct. In such a situation, we *DO* care about the previous sequence, but additionally, we wish to track the uses resulting from the following incomplete sequences: Retain -> CanRelease -> Release (TopDown) Retain <- Use <- Release (BottomUp) *NOTE* This patch looks large but the most of it consists of updating test cases. Additionally this fix exposed an additional bug. I removed the test case that expressed said bug and will recommit it with the fix in a little bit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178921 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-05 22:54:28 +00:00
entry:
%t1 = bitcast void (...)* %block to i8*
; CHECK: tail call i8* @objc_retain
%t2 = tail call i8* @objc_retain(i8* %t1)
; CHECK: tail call i8* @objc_retainBlock
%t3 = tail call i8* @objc_retainBlock(i8* %t1), !clang.arc.copy_on_escape !0
%t4 = bitcast i8* %t3 to void (...)*
%store = select i1 undef, void (...)** %store1, void (...)** %store2
store void (...)* %t4, void (...)** %store, align 8
; CHECK: call void @objc_release
call void @objc_release(i8* %t1)
ret void
; CHECK: }
}
define void @selecttest_a(void (...)** %store1, void (...)** %store2,
void (...)* %block) {
; CHECK: define void @selecttest_a
The promised test case for r175939. This test makes sure that the ObjCARC escape analysis looks at the uses of instructions which copy the block pointer value by checking all four cases where that can occur. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177232 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-17 08:42:58 +00:00
entry:
%t1 = bitcast void (...)* %block to i8*
; CHECK-NOT: tail call i8* @objc_retain
%t2 = tail call i8* @objc_retain(i8* %t1)
; CHECK: tail call i8* @objc_retainBlock
%t3 = tail call i8* @objc_retainBlock(i8* %t1), !clang.arc.copy_on_escape !0
%t4 = bitcast i8* %t3 to void (...)*
%store = select i1 undef, void (...)** %store1, void (...)** %store2
store void (...)* %t4, void (...)** %store, align 8
; CHECK-NOT: call void @objc_release
Properly model precise lifetime when given an incomplete dataflow sequence. The normal dataflow sequence in the ARC optimizer consists of the following states: Retain -> CanRelease -> Use -> Release The optimizer before this patch stored the uses that determine the lifetime of the retainable object pointer when it bottom up hits a retain or when top down it hits a release. This is correct for an imprecise lifetime scenario since what we are trying to do is remove retains/releases while making sure that no ``CanRelease'' (which is usually a call) deallocates the given pointer before we get to the ``Use'' (since that would cause a segfault). If we are considering the precise lifetime scenario though, this is not correct. In such a situation, we *DO* care about the previous sequence, but additionally, we wish to track the uses resulting from the following incomplete sequences: Retain -> CanRelease -> Release (TopDown) Retain <- Use <- Release (BottomUp) *NOTE* This patch looks large but the most of it consists of updating test cases. Additionally this fix exposed an additional bug. I removed the test case that expressed said bug and will recommit it with the fix in a little bit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178921 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-05 22:54:28 +00:00
call void @objc_release(i8* %t1), !clang.imprecise_release !0
The promised test case for r175939. This test makes sure that the ObjCARC escape analysis looks at the uses of instructions which copy the block pointer value by checking all four cases where that can occur. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177232 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-17 08:42:58 +00:00
ret void
Properly model precise lifetime when given an incomplete dataflow sequence. The normal dataflow sequence in the ARC optimizer consists of the following states: Retain -> CanRelease -> Use -> Release The optimizer before this patch stored the uses that determine the lifetime of the retainable object pointer when it bottom up hits a retain or when top down it hits a release. This is correct for an imprecise lifetime scenario since what we are trying to do is remove retains/releases while making sure that no ``CanRelease'' (which is usually a call) deallocates the given pointer before we get to the ``Use'' (since that would cause a segfault). If we are considering the precise lifetime scenario though, this is not correct. In such a situation, we *DO* care about the previous sequence, but additionally, we wish to track the uses resulting from the following incomplete sequences: Retain -> CanRelease -> Release (TopDown) Retain <- Use <- Release (BottomUp) *NOTE* This patch looks large but the most of it consists of updating test cases. Additionally this fix exposed an additional bug. I removed the test case that expressed said bug and will recommit it with the fix in a little bit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178921 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-05 22:54:28 +00:00
; CHECK: }
The promised test case for r175939. This test makes sure that the ObjCARC escape analysis looks at the uses of instructions which copy the block pointer value by checking all four cases where that can occur. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177232 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-17 08:42:58 +00:00
}
define void @phinodetest(void (...)** %storage1,
void (...)** %storage2,
void (...)* %block) {
; CHECK: define void @phinodetest
Properly model precise lifetime when given an incomplete dataflow sequence. The normal dataflow sequence in the ARC optimizer consists of the following states: Retain -> CanRelease -> Use -> Release The optimizer before this patch stored the uses that determine the lifetime of the retainable object pointer when it bottom up hits a retain or when top down it hits a release. This is correct for an imprecise lifetime scenario since what we are trying to do is remove retains/releases while making sure that no ``CanRelease'' (which is usually a call) deallocates the given pointer before we get to the ``Use'' (since that would cause a segfault). If we are considering the precise lifetime scenario though, this is not correct. In such a situation, we *DO* care about the previous sequence, but additionally, we wish to track the uses resulting from the following incomplete sequences: Retain -> CanRelease -> Release (TopDown) Retain <- Use <- Release (BottomUp) *NOTE* This patch looks large but the most of it consists of updating test cases. Additionally this fix exposed an additional bug. I removed the test case that expressed said bug and will recommit it with the fix in a little bit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178921 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-05 22:54:28 +00:00
entry:
%t1 = bitcast void (...)* %block to i8*
; CHECK: tail call i8* @objc_retain
%t2 = tail call i8* @objc_retain(i8* %t1)
; CHECK: tail call i8* @objc_retainBlock
%t3 = tail call i8* @objc_retainBlock(i8* %t1), !clang.arc.copy_on_escape !0
%t4 = bitcast i8* %t3 to void (...)*
br i1 undef, label %store1_set, label %store2_set
; CHECK: store1_set:
store1_set:
br label %end
store2_set:
br label %end
end:
; CHECK: end:
%storage = phi void (...)** [ %storage1, %store1_set ], [ %storage2, %store2_set]
store void (...)* %t4, void (...)** %storage, align 8
; CHECK: call void @objc_release
call void @objc_release(i8* %t1)
ret void
; CHECK: }
}
define void @phinodetest_a(void (...)** %storage1,
void (...)** %storage2,
void (...)* %block) {
; CHECK: define void @phinodetest_a
The promised test case for r175939. This test makes sure that the ObjCARC escape analysis looks at the uses of instructions which copy the block pointer value by checking all four cases where that can occur. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177232 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-17 08:42:58 +00:00
entry:
%t1 = bitcast void (...)* %block to i8*
; CHECK-NOT: tail call i8* @objc_retain
%t2 = tail call i8* @objc_retain(i8* %t1)
; CHECK: tail call i8* @objc_retainBlock
%t3 = tail call i8* @objc_retainBlock(i8* %t1), !clang.arc.copy_on_escape !0
%t4 = bitcast i8* %t3 to void (...)*
br i1 undef, label %store1_set, label %store2_set
store1_set:
br label %end
store2_set:
br label %end
end:
%storage = phi void (...)** [ %storage1, %store1_set ], [ %storage2, %store2_set]
store void (...)* %t4, void (...)** %storage, align 8
; CHECK-NOT: call void @objc_release
Properly model precise lifetime when given an incomplete dataflow sequence. The normal dataflow sequence in the ARC optimizer consists of the following states: Retain -> CanRelease -> Use -> Release The optimizer before this patch stored the uses that determine the lifetime of the retainable object pointer when it bottom up hits a retain or when top down it hits a release. This is correct for an imprecise lifetime scenario since what we are trying to do is remove retains/releases while making sure that no ``CanRelease'' (which is usually a call) deallocates the given pointer before we get to the ``Use'' (since that would cause a segfault). If we are considering the precise lifetime scenario though, this is not correct. In such a situation, we *DO* care about the previous sequence, but additionally, we wish to track the uses resulting from the following incomplete sequences: Retain -> CanRelease -> Release (TopDown) Retain <- Use <- Release (BottomUp) *NOTE* This patch looks large but the most of it consists of updating test cases. Additionally this fix exposed an additional bug. I removed the test case that expressed said bug and will recommit it with the fix in a little bit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178921 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-05 22:54:28 +00:00
call void @objc_release(i8* %t1), !clang.imprecise_release !0
The promised test case for r175939. This test makes sure that the ObjCARC escape analysis looks at the uses of instructions which copy the block pointer value by checking all four cases where that can occur. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177232 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-17 08:42:58 +00:00
ret void
}
Properly model precise lifetime when given an incomplete dataflow sequence. The normal dataflow sequence in the ARC optimizer consists of the following states: Retain -> CanRelease -> Use -> Release The optimizer before this patch stored the uses that determine the lifetime of the retainable object pointer when it bottom up hits a retain or when top down it hits a release. This is correct for an imprecise lifetime scenario since what we are trying to do is remove retains/releases while making sure that no ``CanRelease'' (which is usually a call) deallocates the given pointer before we get to the ``Use'' (since that would cause a segfault). If we are considering the precise lifetime scenario though, this is not correct. In such a situation, we *DO* care about the previous sequence, but additionally, we wish to track the uses resulting from the following incomplete sequences: Retain -> CanRelease -> Release (TopDown) Retain <- Use <- Release (BottomUp) *NOTE* This patch looks large but the most of it consists of updating test cases. Additionally this fix exposed an additional bug. I removed the test case that expressed said bug and will recommit it with the fix in a little bit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178921 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-05 22:54:28 +00:00
Reduced dont-infinite-loop-during-block-escape-analysis.ll with bugpoint and moved it to retain-block-escape-analysis.ll. *NOTE* I verified that the original bug behind dont-infinite-loop-during-block-escape-analysis.ll occurs when using opt on retain-block-escape-analysis.ll. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177240 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-17 21:31:12 +00:00
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; This test makes sure that we do not hang clang when visiting a use ;
; cycle caused by phi nodes during objc-arc analysis. *NOTE* This ;
; test case looks a little convoluted since it was produced by ;
; bugpoint. ;
; ;
; bugzilla://14551 ;
; rdar://12851911 ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
define void @phinode_use_cycle(i8* %block) uwtable optsize ssp {
; CHECK: define void @phinode_use_cycle(i8* %block)
entry:
br label %for.body
for.body: ; preds = %if.then, %for.body, %entry
%block.05 = phi void (...)* [ null, %entry ], [ %1, %if.then ], [ %block.05, %for.body ]
br i1 undef, label %for.body, label %if.then
if.then: ; preds = %for.body
%0 = call i8* @objc_retainBlock(i8* %block), !clang.arc.copy_on_escape !0
%1 = bitcast i8* %0 to void (...)*
%2 = bitcast void (...)* %block.05 to i8*
call void @objc_release(i8* %2) nounwind, !clang.imprecise_release !0
br label %for.body
}
The promised test case for r175939. This test makes sure that the ObjCARC escape analysis looks at the uses of instructions which copy the block pointer value by checking all four cases where that can occur. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177232 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-17 08:42:58 +00:00
!0 = metadata !{}
Reference in New Issue Copy Permalink