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/invoke-donothing-assert.ll

74 lines
2.0 KiB
LLVM
Raw Normal View History

SelectionDAG: If llvm.donothing has a landingpad, we should clear CurrentCallSite to avoid an assertion failure: assert(MMI.getCurrentCallSite() == 0 && "Overlapping call sites!"); rdar://problem/13228754 llvm-svn: 176154
2013-02-27 10:11:57 +08:00
; RUN: llc < %s -mtriple=armv7-apple-ios | FileCheck %s
; This testcase makes sure we can handle invoke @llvm.donothing without
; assertion failure.
Revert r176154 in favor of a better approach. Code generation makes some basic assumptions about the IR it's been given. In particular, if there is only one 'invoke' in the function, then that invoke won't be going away. However, with the advent of the `llvm.donothing' intrinsic, those invokes may go away. If all of them go away, the landing pad no longer has any users. This confuses the back-end, which asserts. This happens with SjLj exceptions, because that's the model that modifies the IR based on there being invokes, etc. in the function. Remove any invokes of `llvm.donothing' during SjLj EH preparation. This will give us a CFG that the back-end won't be confused about. If all of the invokes in a function are removed, then the SjLj EH prepare pass won't insert the bogus code the relies upon the invokes being there. <rdar://problem/13228754&13316637> llvm-svn: 176677
2013-03-08 10:21:08 +08:00
; <rdar://problem/13228754> & <rdar://problem/13316637>
SelectionDAG: If llvm.donothing has a landingpad, we should clear CurrentCallSite to avoid an assertion failure: assert(MMI.getCurrentCallSite() == 0 && "Overlapping call sites!"); rdar://problem/13228754 llvm-svn: 176154
2013-02-27 10:11:57 +08:00
Revert r176154 in favor of a better approach. Code generation makes some basic assumptions about the IR it's been given. In particular, if there is only one 'invoke' in the function, then that invoke won't be going away. However, with the advent of the `llvm.donothing' intrinsic, those invokes may go away. If all of them go away, the landing pad no longer has any users. This confuses the back-end, which asserts. This happens with SjLj exceptions, because that's the model that modifies the IR based on there being invokes, etc. in the function. Remove any invokes of `llvm.donothing' during SjLj EH preparation. This will give us a CFG that the back-end won't be confused about. If all of the invokes in a function are removed, then the SjLj EH prepare pass won't insert the bogus code the relies upon the invokes being there. <rdar://problem/13228754&13316637> llvm-svn: 176677
2013-03-08 10:21:08 +08:00
; CHECK: .globl _foo
define void @foo() {
SelectionDAG: If llvm.donothing has a landingpad, we should clear CurrentCallSite to avoid an assertion failure: assert(MMI.getCurrentCallSite() == 0 && "Overlapping call sites!"); rdar://problem/13228754 llvm-svn: 176154
2013-02-27 10:11:57 +08:00
invoke.cont:
invoke void @callA()
to label %invoke.cont25 unwind label %lpad2
invoke.cont25:
invoke void @llvm.donothing()
to label %invoke.cont27 unwind label %lpad15
invoke.cont27:
invoke void @callB()
to label %invoke.cont75 unwind label %lpad15
invoke.cont75:
ret void
lpad2:
%0 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_sj0 to i8*)
cleanup
br label %eh.resume
lpad15:
%1 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_sj0 to i8*)
cleanup
br label %eh.resume
eh.resume:
resume { i8*, i32 } zeroinitializer
}
Revert r176154 in favor of a better approach. Code generation makes some basic assumptions about the IR it's been given. In particular, if there is only one 'invoke' in the function, then that invoke won't be going away. However, with the advent of the `llvm.donothing' intrinsic, those invokes may go away. If all of them go away, the landing pad no longer has any users. This confuses the back-end, which asserts. This happens with SjLj exceptions, because that's the model that modifies the IR based on there being invokes, etc. in the function. Remove any invokes of `llvm.donothing' during SjLj EH preparation. This will give us a CFG that the back-end won't be confused about. If all of the invokes in a function are removed, then the SjLj EH prepare pass won't insert the bogus code the relies upon the invokes being there. <rdar://problem/13228754&13316637> llvm-svn: 176677
2013-03-08 10:21:08 +08:00
; CHECK: .globl _bar
define linkonce_odr void @bar(i32* %a) {
if.end.i.i.i:
invoke void @llvm.donothing()
to label %call.i.i.i.noexc unwind label %eh.resume
call.i.i.i.noexc:
br i1 false, label %cleanup, label %new.notnull.i.i
new.notnull.i.i:
br label %cleanup
cleanup:
[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-28 05:17:42 +08:00
%0 = load i32, i32* %a, align 4
Revert r176154 in favor of a better approach. Code generation makes some basic assumptions about the IR it's been given. In particular, if there is only one 'invoke' in the function, then that invoke won't be going away. However, with the advent of the `llvm.donothing' intrinsic, those invokes may go away. If all of them go away, the landing pad no longer has any users. This confuses the back-end, which asserts. This happens with SjLj exceptions, because that's the model that modifies the IR based on there being invokes, etc. in the function. Remove any invokes of `llvm.donothing' during SjLj EH preparation. This will give us a CFG that the back-end won't be confused about. If all of the invokes in a function are removed, then the SjLj EH prepare pass won't insert the bogus code the relies upon the invokes being there. <rdar://problem/13228754&13316637> llvm-svn: 176677
2013-03-08 10:21:08 +08:00
%inc294 = add nsw i32 %0, 4
store i32 %inc294, i32* %a, align 4
br i1 false, label %_ZN3lol5ArrayIivvvvvvvED1Ev.exit, label %delete.notnull.i.i.i1409
delete.notnull.i.i.i1409:
br label %_ZN3lol5ArrayIivvvvvvvED1Ev.exit
_ZN3lol5ArrayIivvvvvvvED1Ev.exit:
ret void
eh.resume:
%1 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_sj0 to i8*)
cleanup
%2 = extractvalue { i8*, i32 } %1, 0
%3 = extractvalue { i8*, i32 } %1, 1
%lpad.val = insertvalue { i8*, i32 } undef, i8* %2, 0
%lpad.val395 = insertvalue { i8*, i32 } %lpad.val, i32 %3, 1
resume { i8*, i32 } %lpad.val395
}
declare void @callA()
SelectionDAG: If llvm.donothing has a landingpad, we should clear CurrentCallSite to avoid an assertion failure: assert(MMI.getCurrentCallSite() == 0 && "Overlapping call sites!"); rdar://problem/13228754 llvm-svn: 176154
2013-02-27 10:11:57 +08:00
declare void @callB()
declare void @llvm.donothing() nounwind readnone
Revert r176154 in favor of a better approach. Code generation makes some basic assumptions about the IR it's been given. In particular, if there is only one 'invoke' in the function, then that invoke won't be going away. However, with the advent of the `llvm.donothing' intrinsic, those invokes may go away. If all of them go away, the landing pad no longer has any users. This confuses the back-end, which asserts. This happens with SjLj exceptions, because that's the model that modifies the IR based on there being invokes, etc. in the function. Remove any invokes of `llvm.donothing' during SjLj EH preparation. This will give us a CFG that the back-end won't be confused about. If all of the invokes in a function are removed, then the SjLj EH prepare pass won't insert the bogus code the relies upon the invokes being there. <rdar://problem/13228754&13316637> llvm-svn: 176677
2013-03-08 10:21:08 +08:00
declare i32 @__gxx_personality_sj0(...)