maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Transforms/SimplifyCFG/seh-nounwind.ll

32 lines
814 B
LLVM
Raw Normal View History

Don't promote asynch EH invokes of nounwind functions to calls If the landingpad of the invoke is using a personality function that catches asynch exceptions, then it can catch a trap. Also add some landingpads to invalid LLVM IR test cases that lack them. Over-the-shoulder reviewed by David Majnemer. llvm-svn: 228782
2015-02-11 09:23:16 +08:00
; RUN: opt -S -simplifycfg < %s | FileCheck %s
; Don't remove invokes of nounwind functions if the personality handles async
; exceptions. The @div function in this test can fault, even though it can't
; throw a synchronous exception.
define i32 @div(i32 %n, i32 %d) nounwind {
entry:
%div = sdiv i32 %n, %d
ret i32 %div
}
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 i32 @main() nounwind personality i8* bitcast (i32 (...)* @__C_specific_handler to i8*) {
Don't promote asynch EH invokes of nounwind functions to calls If the landingpad of the invoke is using a personality function that catches asynch exceptions, then it can catch a trap. Also add some landingpads to invalid LLVM IR test cases that lack them. Over-the-shoulder reviewed by David Majnemer. llvm-svn: 228782
2015-02-11 09:23:16 +08:00
entry:
%call = invoke i32 @div(i32 10, i32 0)
to label %__try.cont unwind label %lpad
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
%0 = landingpad { i8*, i32 }
Don't promote asynch EH invokes of nounwind functions to calls If the landingpad of the invoke is using a personality function that catches asynch exceptions, then it can catch a trap. Also add some landingpads to invalid LLVM IR test cases that lack them. Over-the-shoulder reviewed by David Majnemer. llvm-svn: 228782
2015-02-11 09:23:16 +08:00
catch i8* null
br label %__try.cont
__try.cont:
%retval.0 = phi i32 [ %call, %entry ], [ 0, %lpad ]
ret i32 %retval.0
}
; CHECK-LABEL: define i32 @main()
; CHECK: invoke i32 @div(i32 10, i32 0)
declare i32 @__C_specific_handler(...)