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

64 lines
1.9 KiB
LLVM
Raw Normal View History

[Stackmaps] Enable invoking the patchpoint intrinsic. Patch by Kevin Modzelewski Reviewers: atrick, ributzka Reviewed By: ributzka Subscribers: llvm-commits, reames Differential Revision: http://reviews.llvm.org/D5634 llvm-svn: 220055
2014-10-18 01:39:00 +08:00
; RUN: llc -mtriple=x86_64-unknown-linux -mcpu=corei7 < %s | FileCheck %s
; Test invoking of patchpoints
;
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 i64 @patchpoint_invoke(i64 %p1, i64 %p2) personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) {
[Stackmaps] Enable invoking the patchpoint intrinsic. Patch by Kevin Modzelewski Reviewers: atrick, ributzka Reviewed By: ributzka Subscribers: llvm-commits, reames Differential Revision: http://reviews.llvm.org/D5634 llvm-svn: 220055
2014-10-18 01:39:00 +08:00
entry:
; CHECK-LABEL: patchpoint_invoke:
Centralize handling of the eh_begin and eh_end labels. This removes a bit of duplicated code and more importantly, remembers the labels so that they don't need to be looked up by name. This in turn allows for any name to be used and avoids a crash if the name we wanted was already taken. llvm-svn: 230772
2015-02-28 02:18:39 +08:00
; CHECK-NEXT: [[FUNC_BEGIN:.L.*]]:
[Stackmaps] Enable invoking the patchpoint intrinsic. Patch by Kevin Modzelewski Reviewers: atrick, ributzka Reviewed By: ributzka Subscribers: llvm-commits, reames Differential Revision: http://reviews.llvm.org/D5634 llvm-svn: 220055
2014-10-18 01:39:00 +08:00
; CHECK-NEXT: .cfi_startproc
; CHECK: .cfi_lsda 3, [[EXCEPTION_LABEL:.L[^ ]*]]
; CHECK: pushq %rbp
; Unfortunately, hardcode the name of the label that begins the patchpoint:
; CHECK: .Ltmp0:
; CHECK: movabsq $-559038736, %r11
; CHECK-NEXT: callq *%r11
; CHECK-NEXT: xchgw %ax, %ax
; CHECK-NEXT: [[PP_END:.L.*]]:
; CHECK: ret
%resolveCall = inttoptr i64 -559038736 to i8*
[opaque pointer type] Add textual IR support for explicit type parameter to the invoke instruction Same as r235145 for the call instruction - the justification, tradeoffs, etc are all the same. The conversion script worked the same without any false negatives (after replacing 'call' with 'invoke'). llvm-svn: 235755
2015-04-25 03:32:54 +08:00
%result = invoke i64 (i64, i32, i8*, i32, ...) @llvm.experimental.patchpoint.i64(i64 2, i32 15, i8* %resolveCall, i32 1, i64 %p1, i64 %p2)
[Stackmaps] Enable invoking the patchpoint intrinsic. Patch by Kevin Modzelewski Reviewers: atrick, ributzka Reviewed By: ributzka Subscribers: llvm-commits, reames Differential Revision: http://reviews.llvm.org/D5634 llvm-svn: 220055
2014-10-18 01:39:00 +08:00
to label %success unwind label %threw
success:
ret i64 %result
threw:
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 }
[Stackmaps] Enable invoking the patchpoint intrinsic. Patch by Kevin Modzelewski Reviewers: atrick, ributzka Reviewed By: ributzka Subscribers: llvm-commits, reames Differential Revision: http://reviews.llvm.org/D5634 llvm-svn: 220055
2014-10-18 01:39:00 +08:00
catch i8* null
ret i64 0
}
; Verify that the exception table was emitted:
; CHECK: [[EXCEPTION_LABEL]]:
; CHECK-NEXT: .byte 255
; CHECK-NEXT: .byte 3
; CHECK-NEXT: .byte 21
; CHECK-NEXT: .byte 3
; CHECK-NEXT: .byte 13
; Verify that the unwind data covers the entire patchpoint region:
Fix a bit of confusion about .set and produce more readable assembly. Every target we support has support for assembly that looks like a = b - c .long a What is special about MachO is that the above combination suppresses the production of a relocation. With this change we avoid producing the intermediary labels when they don't add any value. llvm-svn: 220256
2014-10-21 09:17:30 +08:00
; CHECK-NEXT: .long .Ltmp0-[[FUNC_BEGIN]]
; CHECK-NEXT: .long [[PP_END]]-.Ltmp0
[Stackmaps] Enable invoking the patchpoint intrinsic. Patch by Kevin Modzelewski Reviewers: atrick, ributzka Reviewed By: ributzka Subscribers: llvm-commits, reames Differential Revision: http://reviews.llvm.org/D5634 llvm-svn: 220055
2014-10-18 01:39:00 +08:00
; Verify that the stackmap section got emitted:
; CHECK-LABEL: __LLVM_StackMaps:
; Header
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
; CHECK-NEXT: .byte 2
[Stackmaps] Enable invoking the patchpoint intrinsic. Patch by Kevin Modzelewski Reviewers: atrick, ributzka Reviewed By: ributzka Subscribers: llvm-commits, reames Differential Revision: http://reviews.llvm.org/D5634 llvm-svn: 220055
2014-10-18 01:39:00 +08:00
; CHECK-NEXT: .byte 0
; CHECK-NEXT: .short 0
; Num Functions
; CHECK-NEXT: .long 1
; Num LargeConstants
; CHECK-NEXT: .long 0
; Num Callsites
; CHECK-NEXT: .long 1
; CHECK-NEXT: .quad patchpoint_invoke
declare void @llvm.experimental.stackmap(i64, i32, ...)
declare void @llvm.experimental.patchpoint.void(i64, i32, i8*, i32, ...)
declare i64 @llvm.experimental.patchpoint.i64(i64, i32, i8*, i32, ...)
declare i32 @__gxx_personality_v0(...)