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/2011-05-04-MultipleLandingP...

89 lines
2.1 KiB
LLVM
Raw Normal View History

SjLj EH could produce a machine basic block that legitimately has more than one landing pad as its successor. SjLj exception handling jumps to the correct landing pad via a switch statement that's generated right before code-gen. Loosen the constraint in the machine instruction verifier to allow for this. Note, this isn't the most rigorous check since we cannot determine where that switch statement came from. But it's marginally better than turning this check off when SjLj exceptions are used. <rdar://problem/9187612> llvm-svn: 130881
2011-05-05 06:54:05 +08:00
; RUN: llc < %s -verify-machineinstrs
; <rdar://problem/9187612>
target datalayout = "e-p:32:32:32-i1:8:32-i8:8:32-i16:16:32-i32:32:32-i64:32:32-f32:32:32-f64:32:32-v64:64:64-v128:128:128-a0:0:32-n32"
target triple = "thumbv7-apple-darwin"
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
define void @func() unnamed_addr align 2 personality i8* bitcast (i32 (...)* @__gxx_personality_sj0 to i8*) {
SjLj EH could produce a machine basic block that legitimately has more than one landing pad as its successor. SjLj exception handling jumps to the correct landing pad via a switch statement that's generated right before code-gen. Loosen the constraint in the machine instruction verifier to allow for this. Note, this isn't the most rigorous check since we cannot determine where that switch statement came from. But it's marginally better than turning this check off when SjLj exceptions are used. <rdar://problem/9187612> llvm-svn: 130881
2011-05-05 06:54:05 +08:00
entry:
br label %for.cond
for.cond:
%tmp2 = phi i32 [ 0, %entry ], [ %add, %for.cond.backedge ]
%cmp = icmp ult i32 %tmp2, 14
br i1 %cmp, label %for.body, label %for.end
for.body:
%add = add i32 %tmp2, 1
switch i32 %tmp2, label %sw.default [
i32 0, label %sw.bb
i32 1, label %sw.bb
i32 2, label %sw.bb
i32 4, label %sw.bb
i32 5, label %sw.bb
i32 10, label %sw.bb
]
sw.bb:
invoke void @foo()
to label %invoke.cont17 unwind label %lpad
invoke.cont17:
invoke void @foo()
to label %for.cond.backedge unwind label %lpad26
for.cond.backedge:
br label %for.cond
lpad:
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
%exn = landingpad { i8*, i32 }
Convert tests to the new EH model. llvm-svn: 144048
2011-11-08 08:09:27 +08:00
catch i8* null
SjLj EH could produce a machine basic block that legitimately has more than one landing pad as its successor. SjLj exception handling jumps to the correct landing pad via a switch statement that's generated right before code-gen. Loosen the constraint in the machine instruction verifier to allow for this. Note, this isn't the most rigorous check since we cannot determine where that switch statement came from. But it's marginally better than turning this check off when SjLj exceptions are used. <rdar://problem/9187612> llvm-svn: 130881
2011-05-05 06:54:05 +08:00
invoke void @foo()
to label %eh.resume unwind label %terminate.lpad
lpad26:
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
%exn27 = landingpad { i8*, i32 }
Convert tests to the new EH model. llvm-svn: 144048
2011-11-08 08:09:27 +08:00
catch i8* null
SjLj EH could produce a machine basic block that legitimately has more than one landing pad as its successor. SjLj exception handling jumps to the correct landing pad via a switch statement that's generated right before code-gen. Loosen the constraint in the machine instruction verifier to allow for this. Note, this isn't the most rigorous check since we cannot determine where that switch statement came from. But it's marginally better than turning this check off when SjLj exceptions are used. <rdar://problem/9187612> llvm-svn: 130881
2011-05-05 06:54:05 +08:00
invoke void @foo()
to label %eh.resume unwind label %terminate.lpad
sw.default:
br label %for.cond.backedge
for.end:
invoke void @foo()
to label %call8.i.i.i.noexc unwind label %lpad44
call8.i.i.i.noexc:
ret void
lpad44:
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
%exn45 = landingpad { i8*, i32 }
Convert tests to the new EH model. llvm-svn: 144048
2011-11-08 08:09:27 +08:00
catch i8* null
SjLj EH could produce a machine basic block that legitimately has more than one landing pad as its successor. SjLj exception handling jumps to the correct landing pad via a switch statement that's generated right before code-gen. Loosen the constraint in the machine instruction verifier to allow for this. Note, this isn't the most rigorous check since we cannot determine where that switch statement came from. But it's marginally better than turning this check off when SjLj exceptions are used. <rdar://problem/9187612> llvm-svn: 130881
2011-05-05 06:54:05 +08:00
invoke void @foo()
to label %eh.resume unwind label %terminate.lpad
eh.resume:
Convert tests to the new EH model. llvm-svn: 144048
2011-11-08 08:09:27 +08:00
%exn.slot.0 = phi { i8*, i32 } [ %exn27, %lpad26 ], [ %exn, %lpad ], [ %exn45, %lpad44 ]
resume { i8*, i32 } %exn.slot.0
SjLj EH could produce a machine basic block that legitimately has more than one landing pad as its successor. SjLj exception handling jumps to the correct landing pad via a switch statement that's generated right before code-gen. Loosen the constraint in the machine instruction verifier to allow for this. Note, this isn't the most rigorous check since we cannot determine where that switch statement came from. But it's marginally better than turning this check off when SjLj exceptions are used. <rdar://problem/9187612> llvm-svn: 130881
2011-05-05 06:54:05 +08:00
terminate.lpad:
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
%exn51 = landingpad { i8*, i32 }
Convert tests to the new EH model. llvm-svn: 144048
2011-11-08 08:09:27 +08:00
catch i8* null
SjLj EH could produce a machine basic block that legitimately has more than one landing pad as its successor. SjLj exception handling jumps to the correct landing pad via a switch statement that's generated right before code-gen. Loosen the constraint in the machine instruction verifier to allow for this. Note, this isn't the most rigorous check since we cannot determine where that switch statement came from. But it's marginally better than turning this check off when SjLj exceptions are used. <rdar://problem/9187612> llvm-svn: 130881
2011-05-05 06:54:05 +08:00
tail call void @_ZSt9terminatev() noreturn nounwind
unreachable
}
declare void @foo()
declare i32 @__gxx_personality_sj0(...)
declare void @_Unwind_SjLj_Resume_or_Rethrow(i8*)
declare void @_ZSt9terminatev()
IR: Make metadata typeless in assembly Now that `Metadata` is typeless, reflect that in the assembly. These are the matching assembly changes for the metadata/value split in r223802. - Only use the `metadata` type when referencing metadata from a call intrinsic -- i.e., only when it's used as a `Value`. - Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode` when referencing it from call intrinsics. So, assembly like this: define @foo(i32 %v) { call void @llvm.foo(metadata !{i32 %v}, metadata !0) call void @llvm.foo(metadata !{i32 7}, metadata !0) call void @llvm.foo(metadata !1, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{metadata !3}, metadata !0) ret void, !bar !2 } !0 = metadata !{metadata !2} !1 = metadata !{i32* @global} !2 = metadata !{metadata !3} !3 = metadata !{} turns into this: define @foo(i32 %v) { call void @llvm.foo(metadata i32 %v, metadata !0) call void @llvm.foo(metadata i32 7, metadata !0) call void @llvm.foo(metadata i32* @global, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{!3}, metadata !0) ret void, !bar !2 } !0 = !{!2} !1 = !{i32* @global} !2 = !{!3} !3 = !{} I wrote an upgrade script that handled almost all of the tests in llvm and many of the tests in cfe (even handling many `CHECK` lines). I've attached it (or will attach it in a moment if you're speedy) to PR21532 to help everyone update their out-of-tree testcases. This is part of PR21532. llvm-svn: 224257
2014-12-16 03:07:53 +08:00
!0 = !{!"any pointer", !1}
!1 = !{!"omnipotent char", !2}
[Verifier] Add verification for TBAA metadata Summary: This change adds some verification in the IR verifier around struct path TBAA metadata. Other than some basic sanity checks (e.g. we get constant integers where we expect constant integers), this checks: - That by the time an struct access tuple `(base-type, offset)` is "reduced" to a scalar base type, the offset is `0`. For instance, in C++ you can't start from, say `("struct-a", 16)`, and end up with `("int", 4)` -- by the time the base type is `"int"`, the offset better be zero. In particular, a variant of this invariant is needed for `llvm::getMostGenericTBAA` to be correct. - That there are no cycles in a struct path. - That struct type nodes have their offsets listed in an ascending order. - That when generating the struct access path, you eventually reach the access type listed in the tbaa tag node. Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26438 llvm-svn: 289402
2016-12-12 04:07:15 +08:00
!2 = !{!"Simple C/C++ TBAA"}
IR: Make metadata typeless in assembly Now that `Metadata` is typeless, reflect that in the assembly. These are the matching assembly changes for the metadata/value split in r223802. - Only use the `metadata` type when referencing metadata from a call intrinsic -- i.e., only when it's used as a `Value`. - Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode` when referencing it from call intrinsics. So, assembly like this: define @foo(i32 %v) { call void @llvm.foo(metadata !{i32 %v}, metadata !0) call void @llvm.foo(metadata !{i32 7}, metadata !0) call void @llvm.foo(metadata !1, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{metadata !3}, metadata !0) ret void, !bar !2 } !0 = metadata !{metadata !2} !1 = metadata !{i32* @global} !2 = metadata !{metadata !3} !3 = metadata !{} turns into this: define @foo(i32 %v) { call void @llvm.foo(metadata i32 %v, metadata !0) call void @llvm.foo(metadata i32 7, metadata !0) call void @llvm.foo(metadata i32* @global, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{!3}, metadata !0) ret void, !bar !2 } !0 = !{!2} !1 = !{i32* @global} !2 = !{!3} !3 = !{} I wrote an upgrade script that handled almost all of the tests in llvm and many of the tests in cfe (even handling many `CHECK` lines). I've attached it (or will attach it in a moment if you're speedy) to PR21532 to help everyone update their out-of-tree testcases. This is part of PR21532. llvm-svn: 224257
2014-12-16 03:07:53 +08:00
!3 = !{!"bool", !1}
!4 = !{!"int", !1}