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/X86/win32-eh-states.ll

115 lines
4.1 KiB
LLVM
Raw Normal View History

[WinEH] Start inserting state number stores for C++ EH This moves all the state numbering code for C++ EH to WinEHPrepare so that we can call it from the X86 state numbering IR pass that runs before isel. Now we just call the same state numbering machinery and insert a bunch of stores. It also populates MachineModuleInfo with information about the current function. llvm-svn: 238514
2015-05-29 06:00:24 +08:00
; RUN: llc -mtriple=i686-pc-windows-msvc < %s | FileCheck %s
; Based on this source:
; extern "C" void may_throw(int);
; void f() {
; try {
; may_throw(1);
; try {
; may_throw(2);
; } catch (int) {
; may_throw(3);
; }
; } catch (int) {
; may_throw(4);
; }
; }
%rtti.TypeDescriptor2 = type { i8**, i8*, [3 x i8] }
%eh.CatchHandlerType = type { i32, i8* }
declare void @may_throw(i32)
declare i32 @__CxxFrameHandler3(...)
declare void @llvm.eh.begincatch(i8*, i8*)
declare void @llvm.eh.endcatch()
declare i32 @llvm.eh.typeid.for(i8*)
$"\01??_R0H@8" = comdat any
@"\01??_7type_info@@6B@" = external constant i8*
@"\01??_R0H@8" = linkonce_odr global %rtti.TypeDescriptor2 { i8** @"\01??_7type_info@@6B@", i8* null, [3 x i8] c".H\00" }, comdat
@llvm.eh.handlertype.H.0 = private unnamed_addr constant %eh.CatchHandlerType { i32 0, i8* bitcast (%rtti.TypeDescriptor2* @"\01??_R0H@8" to i8*) }, section "llvm.metadata"
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 @f() #0 personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*) {
[WinEH] Start inserting state number stores for C++ EH This moves all the state numbering code for C++ EH to WinEHPrepare so that we can call it from the X86 state numbering IR pass that runs before isel. Now we just call the same state numbering machinery and insert a bunch of stores. It also populates MachineModuleInfo with information about the current function. llvm-svn: 238514
2015-05-29 06:00:24 +08:00
entry:
invoke void @may_throw(i32 1)
to label %invoke.cont unwind label %lpad
invoke.cont: ; preds = %entry
invoke void @may_throw(i32 2)
to label %try.cont.9 unwind label %lpad.1
try.cont.9: ; preds = %invoke.cont.3, %invoke.cont, %catch.7
; FIXME: Something about our CFG breaks TailDuplication. This empy asm blocks
; it so we can focus on testing the state numbering.
call void asm sideeffect "", "~{dirflag},~{fpsr},~{flags}"()
ret void
lpad: ; preds = %catch, %entry
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 }
[WinEH] Start inserting state number stores for C++ EH This moves all the state numbering code for C++ EH to WinEHPrepare so that we can call it from the X86 state numbering IR pass that runs before isel. Now we just call the same state numbering machinery and insert a bunch of stores. It also populates MachineModuleInfo with information about the current function. llvm-svn: 238514
2015-05-29 06:00:24 +08:00
catch %eh.CatchHandlerType* @llvm.eh.handlertype.H.0
%1 = extractvalue { i8*, i32 } %0, 0
%2 = extractvalue { i8*, i32 } %0, 1
br label %catch.dispatch.4
lpad.1: ; preds = %invoke.cont
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
%3 = landingpad { i8*, i32 }
[WinEH] Start inserting state number stores for C++ EH This moves all the state numbering code for C++ EH to WinEHPrepare so that we can call it from the X86 state numbering IR pass that runs before isel. Now we just call the same state numbering machinery and insert a bunch of stores. It also populates MachineModuleInfo with information about the current function. llvm-svn: 238514
2015-05-29 06:00:24 +08:00
catch i8* bitcast (%eh.CatchHandlerType* @llvm.eh.handlertype.H.0 to i8*)
%4 = extractvalue { i8*, i32 } %3, 0
%5 = extractvalue { i8*, i32 } %3, 1
%6 = tail call i32 @llvm.eh.typeid.for(i8* bitcast (%eh.CatchHandlerType* @llvm.eh.handlertype.H.0 to i8*)) #3
%matches = icmp eq i32 %5, %6
br i1 %matches, label %catch, label %catch.dispatch.4
catch.dispatch.4: ; preds = %lpad.1, %lpad
%exn.slot.0 = phi i8* [ %4, %lpad.1 ], [ %1, %lpad ]
%ehselector.slot.0 = phi i32 [ %5, %lpad.1 ], [ %2, %lpad ]
%.pre = tail call i32 @llvm.eh.typeid.for(i8* bitcast (%eh.CatchHandlerType* @llvm.eh.handlertype.H.0 to i8*)) #3
%matches6 = icmp eq i32 %ehselector.slot.0, %.pre
br i1 %matches6, label %catch.7, label %eh.resume
catch.7: ; preds = %catch.dispatch.4
tail call void @llvm.eh.begincatch(i8* %exn.slot.0, i8* null) #3
tail call void @may_throw(i32 4)
tail call void @llvm.eh.endcatch() #3
br label %try.cont.9
catch: ; preds = %lpad.1
tail call void @llvm.eh.begincatch(i8* %4, i8* null) #3
invoke void @may_throw(i32 3)
to label %invoke.cont.3 unwind label %lpad
invoke.cont.3: ; preds = %catch
tail call void @llvm.eh.endcatch() #3
br label %try.cont.9
eh.resume: ; preds = %catch.dispatch.4
%lpad.val = insertvalue { i8*, i32 } undef, i8* %exn.slot.0, 0
%lpad.val.12 = insertvalue { i8*, i32 } %lpad.val, i32 %ehselector.slot.0, 1
resume { i8*, i32 } %lpad.val.12
}
; CHECK-LABEL: _f:
Disable FP elimination in funcs using 32-bit MSVC EH personalities The value in 'ebp' acts as an implicit argument to the outlined handlers, and is recovered with frameaddress(1). llvm-svn: 238619
2015-05-30 05:58:11 +08:00
; CHECK: movl $-1, [[state:[-0-9]+]](%ebp)
[WinEH] Start inserting state number stores for C++ EH This moves all the state numbering code for C++ EH to WinEHPrepare so that we can call it from the X86 state numbering IR pass that runs before isel. Now we just call the same state numbering machinery and insert a bunch of stores. It also populates MachineModuleInfo with information about the current function. llvm-svn: 238514
2015-05-29 06:00:24 +08:00
; CHECK: movl $___ehhandler$f, {{.*}}
;
Disable FP elimination in funcs using 32-bit MSVC EH personalities The value in 'ebp' acts as an implicit argument to the outlined handlers, and is recovered with frameaddress(1). llvm-svn: 238619
2015-05-30 05:58:11 +08:00
; CHECK: movl $0, [[state]](%ebp)
[WinEH] Start inserting state number stores for C++ EH This moves all the state numbering code for C++ EH to WinEHPrepare so that we can call it from the X86 state numbering IR pass that runs before isel. Now we just call the same state numbering machinery and insert a bunch of stores. It also populates MachineModuleInfo with information about the current function. llvm-svn: 238514
2015-05-29 06:00:24 +08:00
; CHECK: movl $1, (%esp)
; CHECK: calll _may_throw
;
Disable FP elimination in funcs using 32-bit MSVC EH personalities The value in 'ebp' acts as an implicit argument to the outlined handlers, and is recovered with frameaddress(1). llvm-svn: 238619
2015-05-30 05:58:11 +08:00
; CHECK: movl $1, [[state]](%ebp)
[WinEH] Start inserting state number stores for C++ EH This moves all the state numbering code for C++ EH to WinEHPrepare so that we can call it from the X86 state numbering IR pass that runs before isel. Now we just call the same state numbering machinery and insert a bunch of stores. It also populates MachineModuleInfo with information about the current function. llvm-svn: 238514
2015-05-29 06:00:24 +08:00
; CHECK: movl $2, (%esp)
; CHECK: calll _may_throw
; CHECK-LABEL: _f.catch:
; CHECK: movl $4, Lf$frame_escape_{{[0-9]+.*}}
; CHECK: movl $4, (%esp)
; CHECK: calll _may_throw
; CHECK-LABEL: _f.catch.1:
; CHECK: movl $3, Lf$frame_escape_{{[0-9]+.*}}
; CHECK: movl $3, (%esp)
; CHECK: calll _may_throw
[WinEH] Emit .safeseh directives for all 32-bit exception handlers Use a "safeseh" string attribute to do this. You would think we chould just accumulate the set of personalities like we do on dwarf, but this fails to account for the LSDA-loading thunks we use for __CxxFrameHandler3. Each of those needs to make it into .sxdata as well. The string attribute seemed like the most straightforward approach. llvm-svn: 239448
2015-06-10 09:02:30 +08:00
; CHECK: .safeseh ___ehhandler$f