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/win-catchpad-varargs.ll

102 lines
3.1 KiB
LLVM
Raw Normal View History

Implemented stack symbol table ordering/packing optimization to improve data locality and code size from SP/FP offset encoding. Differential Revision: http://reviews.llvm.org/D15393 llvm-svn: 260917
2016-02-16 07:44:13 +08:00
; RUN: llc -stack-symbol-ordering=0 -mtriple=x86_64-windows-msvc < %s | FileCheck %s --check-prefix=X64
; RUN: llc -stack-symbol-ordering=0 -mtriple=i686-windows-msvc < %s | FileCheck %s --check-prefix=X86
[WinEH] Add test for llvm.va.start in catchpad It already works, but we should have a test for it. This used to be PR23094 in the old model. llvm-svn: 250936
2015-10-22 03:54:40 +08:00
declare void @llvm.va_start(i8*)
declare void @llvm.va_end(i8*)
declare i32 @__CxxFrameHandler3(...)
declare void @g()
define i32 @f(i32 %a, ...) personality i32 (...)* @__CxxFrameHandler3 {
entry:
%ap = alloca i8*
invoke void @g()
to label %return unwind label %catch.dispatch
catch.dispatch: ; preds = %entry
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
%cs1 = catchswitch within none [label %catch] unwind to caller
[WinEH] Add test for llvm.va.start in catchpad It already works, but we should have a test for it. This used to be PR23094 in the old model. llvm-svn: 250936
2015-10-22 03:54:40 +08:00
catch: ; preds = %catch.dispatch
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
%0 = catchpad within %cs1 [i8* null, i32 64, i8* null]
[WinEH] Add test for llvm.va.start in catchpad It already works, but we should have a test for it. This used to be PR23094 in the old model. llvm-svn: 250936
2015-10-22 03:54:40 +08:00
%ap1 = bitcast i8** %ap to i8*
call void @llvm.va_start(i8* %ap1)
%argp.cur = load i8*, i8** %ap
%1 = bitcast i8* %argp.cur to i32*
%arg2 = load i32, i32* %1
call void @llvm.va_end(i8* %ap1)
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
catchret from %0 to label %return
[WinEH] Add test for llvm.va.start in catchpad It already works, but we should have a test for it. This used to be PR23094 in the old model. llvm-svn: 250936
2015-10-22 03:54:40 +08:00
return: ; preds = %entry, %catch
%retval.0 = phi i32 [ %arg2, %catch ], [ -1, %entry ]
ret i32 %retval.0
}
; X64-LABEL: .seh_proc f
; X64: pushq %rbp
[WinEH] Disable most forms of demotion Now that the register allocator knows about the barriers on funclet entry and exit, testing has shown that this is unnecessary. We still demote PHIs on unsplittable blocks due to the differences between the IR CFG and the Machine CFG. llvm-svn: 253619
2015-11-20 07:23:33 +08:00
; X64: subq $64, %rsp
; X64: leaq 64(%rsp), %rbp
; X64: movq $-2, -8(%rbp)
; X64: movl $-1, -20(%rbp) # 4-byte Folded Spill
[WinEH] Add test for llvm.va.start in catchpad It already works, but we should have a test for it. This used to be PR23094 in the old model. llvm-svn: 250936
2015-10-22 03:54:40 +08:00
; X64: callq g
[WinEH] Disable most forms of demotion Now that the register allocator knows about the barriers on funclet entry and exit, testing has shown that this is unnecessary. We still demote PHIs on unsplittable blocks due to the differences between the IR CFG and the Machine CFG. llvm-svn: 253619
2015-11-20 07:23:33 +08:00
; X64: .LBB0_1
; X64: movl -20(%rbp), %eax # 4-byte Reload
; X64: addq $64, %rsp
[WinEH] Add test for llvm.va.start in catchpad It already works, but we should have a test for it. This used to be PR23094 in the old model. llvm-svn: 250936
2015-10-22 03:54:40 +08:00
; X64: popq %rbp
[WinEH] Disable most forms of demotion Now that the register allocator knows about the barriers on funclet entry and exit, testing has shown that this is unnecessary. We still demote PHIs on unsplittable blocks due to the differences between the IR CFG and the Machine CFG. llvm-svn: 253619
2015-11-20 07:23:33 +08:00
; X64-LABEL: "?catch${{[0-9]}}@?0?f@4HA":
; X64: .seh_proc "?catch${{[0-9]}}@?0?f@4HA"
[WinEH] Add test for llvm.va.start in catchpad It already works, but we should have a test for it. This used to be PR23094 in the old model. llvm-svn: 250936
2015-10-22 03:54:40 +08:00
; X64: movq %rdx, 16(%rsp)
; X64: pushq %rbp
[WinEH] Disable most forms of demotion Now that the register allocator knows about the barriers on funclet entry and exit, testing has shown that this is unnecessary. We still demote PHIs on unsplittable blocks due to the differences between the IR CFG and the Machine CFG. llvm-svn: 253619
2015-11-20 07:23:33 +08:00
; X64: subq $32, %rsp
; X64: leaq 64(%rdx), %rbp
[WinEH] Add test for llvm.va.start in catchpad It already works, but we should have a test for it. This used to be PR23094 in the old model. llvm-svn: 250936
2015-10-22 03:54:40 +08:00
; arg2 is at RBP+40:
; start at arg2
; + 8 for arg1
; + 8 for retaddr
; + 8 for RBP
[WinEH] Disable most forms of demotion Now that the register allocator knows about the barriers on funclet entry and exit, testing has shown that this is unnecessary. We still demote PHIs on unsplittable blocks due to the differences between the IR CFG and the Machine CFG. llvm-svn: 253619
2015-11-20 07:23:33 +08:00
; + 64 for stackalloc
; - 64 for setframe
[WinEH] Add test for llvm.va.start in catchpad It already works, but we should have a test for it. This used to be PR23094 in the old model. llvm-svn: 250936
2015-10-22 03:54:40 +08:00
; = 40
[WinEH] Disable most forms of demotion Now that the register allocator knows about the barriers on funclet entry and exit, testing has shown that this is unnecessary. We still demote PHIs on unsplittable blocks due to the differences between the IR CFG and the Machine CFG. llvm-svn: 253619
2015-11-20 07:23:33 +08:00
; X64: movl 24(%rbp), %eax
; X64: movl %eax, -20(%rbp) # 4-byte Spill
; X64: leaq .LBB0_1(%rip), %rax
; X64: addq $32, %rsp
[WinEH] Add test for llvm.va.start in catchpad It already works, but we should have a test for it. This used to be PR23094 in the old model. llvm-svn: 250936
2015-10-22 03:54:40 +08:00
; X64: popq %rbp
; X64: retq # CATCHRET
; X86-LABEL: _f: # @f
; X86: pushl %ebp
; X86: movl %esp, %ebp
; X86: pushl %ebx
; X86: pushl %edi
; X86: pushl %esi
[WinEH] Disable most forms of demotion Now that the register allocator knows about the barriers on funclet entry and exit, testing has shown that this is unnecessary. We still demote PHIs on unsplittable blocks due to the differences between the IR CFG and the Machine CFG. llvm-svn: 253619
2015-11-20 07:23:33 +08:00
; X86: subl $24, %esp
; X86: movl $-1, -36(%ebp)
[WinEH] Add test for llvm.va.start in catchpad It already works, but we should have a test for it. This used to be PR23094 in the old model. llvm-svn: 250936
2015-10-22 03:54:40 +08:00
; X86: calll _g
[WinEH] Disable most forms of demotion Now that the register allocator knows about the barriers on funclet entry and exit, testing has shown that this is unnecessary. We still demote PHIs on unsplittable blocks due to the differences between the IR CFG and the Machine CFG. llvm-svn: 253619
2015-11-20 07:23:33 +08:00
; X86: LBB0_[[retbb:[0-9]+]]:
; X86: movl -36(%ebp), %eax
; X86: addl $24, %esp
[WinEH] Add test for llvm.va.start in catchpad It already works, but we should have a test for it. This used to be PR23094 in the old model. llvm-svn: 250936
2015-10-22 03:54:40 +08:00
; X86: popl %esi
; X86: popl %edi
; X86: popl %ebx
; X86: popl %ebp
; X86: retl
[WinEH] Disable most forms of demotion Now that the register allocator knows about the barriers on funclet entry and exit, testing has shown that this is unnecessary. We still demote PHIs on unsplittable blocks due to the differences between the IR CFG and the Machine CFG. llvm-svn: 253619
2015-11-20 07:23:33 +08:00
; X86: LBB0_[[restorebb:[0-9]+]]: # Block address taken
; X86: addl $12, %ebp
[WinEH] Add test for llvm.va.start in catchpad It already works, but we should have a test for it. This used to be PR23094 in the old model. llvm-svn: 250936
2015-10-22 03:54:40 +08:00
; arg2 is at EBP offset 12:
; + 4 for arg1
; + 4 for retaddr
; + 4 for EBP
[WinEH] Disable most forms of demotion Now that the register allocator knows about the barriers on funclet entry and exit, testing has shown that this is unnecessary. We still demote PHIs on unsplittable blocks due to the differences between the IR CFG and the Machine CFG. llvm-svn: 253619
2015-11-20 07:23:33 +08:00
; X86: movl 12(%ebp), %eax
; X86: movl %eax, -36(%ebp)
; X86: jmp LBB0_[[retbb]]
; X86-LABEL: "?catch${{[0-9]}}@?0?f@4HA":
; X86: pushl %ebp
; X86: addl $12, %ebp
[WinEH] Add test for llvm.va.start in catchpad It already works, but we should have a test for it. This used to be PR23094 in the old model. llvm-svn: 250936
2015-10-22 03:54:40 +08:00
; Done due to mov %esp, %ebp
[WinEH] Disable most forms of demotion Now that the register allocator knows about the barriers on funclet entry and exit, testing has shown that this is unnecessary. We still demote PHIs on unsplittable blocks due to the differences between the IR CFG and the Machine CFG. llvm-svn: 253619
2015-11-20 07:23:33 +08:00
; X86: leal 12(%ebp), %eax
; X86: movl $LBB0_[[restorebb]], %eax
[WinEH] Add test for llvm.va.start in catchpad It already works, but we should have a test for it. This used to be PR23094 in the old model. llvm-svn: 250936
2015-10-22 03:54:40 +08:00
; X86: popl %ebp
; X86: retl # CATCHRET