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/stackmap.ll

470 lines
14 KiB
LLVM
Raw Normal View History

Add -mcpu to stackmap.ll llvm-svn: 196051
2013-12-02 02:17:05 +08:00
; RUN: llc < %s -mtriple=x86_64-apple-darwin -mcpu=corei7 -disable-fp-elim | FileCheck %s
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
;
; Note: Print verbose stackmaps using -debug-only=stackmaps.
; CHECK-LABEL: .section __LLVM_STACKMAPS,__llvm_stackmaps
; CHECK-NEXT: __LLVM_StackMaps:
[Stackmaps] Update the stackmap format to use 64-bit relocations for the function address and properly align all entries. This commit updates the stackmap format to version 1 to indicate the reorganizaion of several fields. This was done in order to align stackmap entries to their natural alignment and to minimize padding. Fixes <rdar://problem/16005902> llvm-svn: 205254
2014-04-01 06:14:04 +08:00
; Header
; CHECK-NEXT: .byte 1
; CHECK-NEXT: .byte 0
; CHECK-NEXT: .short 0
[Stackmaps] Record the stack size of each function that contains a stackmap/patchpoint intrinsic. Re-applying the patch, but this time without using AsmPrinter methods. Reviewed by Andy llvm-svn: 200481
2014-01-31 02:58:27 +08:00
; Num Functions
Make stackmap machineinstrs clobber the scratch regs too. Patchpoints already did this. Doing it for stackmaps is a convenience for the runtime in the event that it needs to scratch register to patch or perform a runtime call thunk. Unlike patchpoints, we just assume the AnyRegCC calling convention. This is the only language and target independent calling convention specific to stackmaps so makes sense. Although the calling convention is not currently used to select the scratch registers. llvm-svn: 202943
2014-03-05 15:08:16 +08:00
; CHECK-NEXT: .long 15
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; Num LargeConstants
[Stackmaps] Update the stackmap format to use 64-bit relocations for the function address and properly align all entries. This commit updates the stackmap format to version 1 to indicate the reorganizaion of several fields. This was done in order to align stackmap entries to their natural alignment and to minimize padding. Fixes <rdar://problem/16005902> llvm-svn: 205254
2014-04-01 06:14:04 +08:00
; CHECK-NEXT: .long 3
; Num Callsites
; CHECK-NEXT: .long 19
; Functions and stack size
; CHECK-NEXT: .quad _constantargs
; CHECK-NEXT: .quad 8
; CHECK-NEXT: .quad _osrinline
; CHECK-NEXT: .quad 24
; CHECK-NEXT: .quad _osrcold
; CHECK-NEXT: .quad 8
; CHECK-NEXT: .quad _propertyRead
; CHECK-NEXT: .quad 8
; CHECK-NEXT: .quad _propertyWrite
; CHECK-NEXT: .quad 8
; CHECK-NEXT: .quad _jsVoidCall
; CHECK-NEXT: .quad 8
; CHECK-NEXT: .quad _jsIntCall
; CHECK-NEXT: .quad 8
; CHECK-NEXT: .quad _spilledValue
; CHECK-NEXT: .quad 56
; CHECK-NEXT: .quad _spilledStackMapValue
; CHECK-NEXT: .quad 56
; CHECK-NEXT: .quad _spillSubReg
; CHECK-NEXT: .quad 56
; CHECK-NEXT: .quad _subRegOffset
; CHECK-NEXT: .quad 56
; CHECK-NEXT: .quad _liveConstant
; CHECK-NEXT: .quad 8
; CHECK-NEXT: .quad _directFrameIdx
; CHECK-NEXT: .quad 56
; CHECK-NEXT: .quad _longid
; CHECK-NEXT: .quad 8
; CHECK-NEXT: .quad _clobberScratch
; CHECK-NEXT: .quad 56
; Large Constants
llvm.experimental.stackmap: fix encoding of large constants. In the stackmap format we advertise the constant field as signed. However, we were determining whether to promote to a 64-bit constant pool based on an unsigned comparison. This fix allows -1 to be encoded as a small constant. llvm-svn: 198816
2014-01-09 08:22:31 +08:00
; CHECK-NEXT: .quad 2147483648
; CHECK-NEXT: .quad 4294967295
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .quad 4294967296
[Stackmaps] Update the stackmap format to use 64-bit relocations for the function address and properly align all entries. This commit updates the stackmap format to version 1 to indicate the reorganizaion of several fields. This was done in order to align stackmap entries to their natural alignment and to minimize padding. Fixes <rdar://problem/16005902> llvm-svn: 205254
2014-04-01 06:14:04 +08:00
; Callsites
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; Constant arguments
;
Grow the stackmap/patchpoint format to hold 64-bit IDs. llvm-svn: 197255
2013-12-14 02:37:10 +08:00
; CHECK-NEXT: .quad 1
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .long L{{.*}}-_constantargs
; CHECK-NEXT: .short 0
llvm.experimental.stackmap: fix encoding of large constants. In the stackmap format we advertise the constant field as signed. However, we were determining whether to promote to a 64-bit constant pool based on an unsigned comparison. This fix allows -1 to be encoded as a small constant. llvm-svn: 198816
2014-01-09 08:22:31 +08:00
; CHECK-NEXT: .short 12
; SmallConstant
; CHECK-NEXT: .byte 4
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short 0
; CHECK-NEXT: .long -1
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; SmallConstant
; CHECK-NEXT: .byte 4
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; CHECK-NEXT: .byte 8
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short 0
llvm.experimental.stackmap: fix encoding of large constants. In the stackmap format we advertise the constant field as signed. However, we were determining whether to promote to a 64-bit constant pool based on an unsigned comparison. This fix allows -1 to be encoded as a small constant. llvm-svn: 198816
2014-01-09 08:22:31 +08:00
; CHECK-NEXT: .long -1
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; SmallConstant
; CHECK-NEXT: .byte 4
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; CHECK-NEXT: .byte 8
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short 0
; CHECK-NEXT: .long 65536
; SmallConstant
; CHECK-NEXT: .byte 4
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; CHECK-NEXT: .byte 8
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short 0
llvm.experimental.stackmap: fix encoding of large constants. In the stackmap format we advertise the constant field as signed. However, we were determining whether to promote to a 64-bit constant pool based on an unsigned comparison. This fix allows -1 to be encoded as a small constant. llvm-svn: 198816
2014-01-09 08:22:31 +08:00
; CHECK-NEXT: .long 2000000000
; SmallConstant
; CHECK-NEXT: .byte 4
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short 0
; CHECK-NEXT: .long 2147483647
; SmallConstant
; CHECK-NEXT: .byte 4
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short 0
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; CHECK-NEXT: .long -1
llvm.experimental.stackmap: fix encoding of large constants. In the stackmap format we advertise the constant field as signed. However, we were determining whether to promote to a 64-bit constant pool based on an unsigned comparison. This fix allows -1 to be encoded as a small constant. llvm-svn: 198816
2014-01-09 08:22:31 +08:00
; SmallConstant
; CHECK-NEXT: .byte 4
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short 0
; CHECK-NEXT: .long -1
; SmallConstant
; CHECK-NEXT: .byte 4
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short 0
; CHECK-NEXT: .long 0
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; LargeConstant at index 0
; CHECK-NEXT: .byte 5
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; CHECK-NEXT: .byte 8
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short 0
; CHECK-NEXT: .long 0
llvm.experimental.stackmap: fix encoding of large constants. In the stackmap format we advertise the constant field as signed. However, we were determining whether to promote to a 64-bit constant pool based on an unsigned comparison. This fix allows -1 to be encoded as a small constant. llvm-svn: 198816
2014-01-09 08:22:31 +08:00
; LargeConstant at index 1
; CHECK-NEXT: .byte 5
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short 0
; CHECK-NEXT: .long 1
; LargeConstant at index 2
; CHECK-NEXT: .byte 5
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short 0
; CHECK-NEXT: .long 2
; SmallConstant
; CHECK-NEXT: .byte 4
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short 0
; CHECK-NEXT: .long -1
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
define void @constantargs() {
entry:
%0 = inttoptr i64 12345 to i8*
llvm.experimental.stackmap: fix encoding of large constants. In the stackmap format we advertise the constant field as signed. However, we were determining whether to promote to a 64-bit constant pool based on an unsigned comparison. This fix allows -1 to be encoded as a small constant. llvm-svn: 198816
2014-01-09 08:22:31 +08:00
tail call void (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.void(i64 1, i32 15, i8* %0, i32 0, i16 65535, i16 -1, i32 65536, i32 2000000000, i32 2147483647, i32 -1, i32 4294967295, i32 4294967296, i64 2147483648, i64 4294967295, i64 4294967296, i64 -1)
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
ret void
}
; Inline OSR Exit
;
Liveness Analysis Pass llvm-svn: 197254
2013-12-14 02:37:03 +08:00
; CHECK-LABEL: .long L{{.*}}-_osrinline
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short 0
; CHECK-NEXT: .short 2
; CHECK-NEXT: .byte 1
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; CHECK-NEXT: .byte 8
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short {{[0-9]+}}
; CHECK-NEXT: .long 0
; CHECK-NEXT: .byte 1
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; CHECK-NEXT: .byte 8
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short {{[0-9]+}}
; CHECK-NEXT: .long 0
define void @osrinline(i64 %a, i64 %b) {
entry:
; Runtime void->void call.
call void inttoptr (i64 -559038737 to void ()*)()
; Followed by inline OSR patchpoint with 12-byte shadow and 2 live vars.
Grow the stackmap/patchpoint format to hold 64-bit IDs. llvm-svn: 197255
2013-12-14 02:37:10 +08:00
call void (i64, i32, ...)* @llvm.experimental.stackmap(i64 3, i32 12, i64 %a, i64 %b)
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
ret void
}
; Cold OSR Exit
;
; 2 live variables in register.
;
Liveness Analysis Pass llvm-svn: 197254
2013-12-14 02:37:03 +08:00
; CHECK-LABEL: .long L{{.*}}-_osrcold
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short 0
; CHECK-NEXT: .short 2
; CHECK-NEXT: .byte 1
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; CHECK-NEXT: .byte 8
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short {{[0-9]+}}
; CHECK-NEXT: .long 0
; CHECK-NEXT: .byte 1
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; CHECK-NEXT: .byte 8
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short {{[0-9]+}}
[Stackmap] Update stackmap unit test to use AnyRegCC. llvm-svn: 196552
2013-12-06 08:28:54 +08:00
; CHECK-NEXT: .long 0
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
define void @osrcold(i64 %a, i64 %b) {
entry:
%test = icmp slt i64 %a, %b
br i1 %test, label %ret, label %cold
cold:
; OSR patchpoint with 12-byte nop-slide and 2 live vars.
%thunk = inttoptr i64 -559038737 to i8*
Grow the stackmap/patchpoint format to hold 64-bit IDs. llvm-svn: 197255
2013-12-14 02:37:10 +08:00
call void (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.void(i64 4, i32 15, i8* %thunk, i32 0, i64 %a, i64 %b)
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
unreachable
ret:
ret void
}
; Property Read
Liveness Analysis Pass llvm-svn: 197254
2013-12-14 02:37:03 +08:00
; CHECK-LABEL: .long L{{.*}}-_propertyRead
[Stackmap] Update stackmap unit test to use AnyRegCC. llvm-svn: 196552
2013-12-06 08:28:54 +08:00
; CHECK-NEXT: .short 0
; CHECK-NEXT: .short 2
; CHECK-NEXT: .byte 1
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short {{[0-9]+}}
; CHECK-NEXT: .long 0
; CHECK-NEXT: .byte 1
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short {{[0-9]+}}
; CHECK-NEXT: .long 0
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
define i64 @propertyRead(i64* %obj) {
entry:
%resolveRead = inttoptr i64 -559038737 to i8*
Grow the stackmap/patchpoint format to hold 64-bit IDs. llvm-svn: 197255
2013-12-14 02:37:10 +08:00
%result = call anyregcc i64 (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.i64(i64 5, i32 15, i8* %resolveRead, i32 1, i64* %obj)
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
%add = add i64 %result, 3
ret i64 %add
}
; Property Write
Liveness Analysis Pass llvm-svn: 197254
2013-12-14 02:37:03 +08:00
; CHECK-LABEL: .long L{{.*}}-_propertyWrite
[Stackmap] Update stackmap unit test to use AnyRegCC. llvm-svn: 196552
2013-12-06 08:28:54 +08:00
; CHECK-NEXT: .short 0
; CHECK-NEXT: .short 2
; CHECK-NEXT: .byte 1
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short {{[0-9]+}}
; CHECK-NEXT: .long 0
; CHECK-NEXT: .byte 1
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short {{[0-9]+}}
; CHECK-NEXT: .long 0
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
define void @propertyWrite(i64 %dummy1, i64* %obj, i64 %dummy2, i64 %a) {
entry:
%resolveWrite = inttoptr i64 -559038737 to i8*
Grow the stackmap/patchpoint format to hold 64-bit IDs. llvm-svn: 197255
2013-12-14 02:37:10 +08:00
call anyregcc void (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.void(i64 6, i32 15, i8* %resolveWrite, i32 2, i64* %obj, i64 %a)
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
ret void
}
; Void JS Call
;
; 2 live variables in registers.
;
Liveness Analysis Pass llvm-svn: 197254
2013-12-14 02:37:03 +08:00
; CHECK-LABEL: .long L{{.*}}-_jsVoidCall
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short 0
; CHECK-NEXT: .short 2
; CHECK-NEXT: .byte 1
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; CHECK-NEXT: .byte 8
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short {{[0-9]+}}
; CHECK-NEXT: .long 0
; CHECK-NEXT: .byte 1
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; CHECK-NEXT: .byte 8
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short {{[0-9]+}}
; CHECK-NEXT: .long 0
define void @jsVoidCall(i64 %dummy1, i64* %obj, i64 %arg, i64 %l1, i64 %l2) {
entry:
%resolveCall = inttoptr i64 -559038737 to i8*
Grow the stackmap/patchpoint format to hold 64-bit IDs. llvm-svn: 197255
2013-12-14 02:37:10 +08:00
call void (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.void(i64 7, i32 15, i8* %resolveCall, i32 2, i64* %obj, i64 %arg, i64 %l1, i64 %l2)
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
ret void
}
; i64 JS Call
;
; 2 live variables in registers.
;
Liveness Analysis Pass llvm-svn: 197254
2013-12-14 02:37:03 +08:00
; CHECK-LABEL: .long L{{.*}}-_jsIntCall
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short 0
; CHECK-NEXT: .short 2
; CHECK-NEXT: .byte 1
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; CHECK-NEXT: .byte 8
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short {{[0-9]+}}
; CHECK-NEXT: .long 0
; CHECK-NEXT: .byte 1
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; CHECK-NEXT: .byte 8
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
; CHECK-NEXT: .short {{[0-9]+}}
; CHECK-NEXT: .long 0
define i64 @jsIntCall(i64 %dummy1, i64* %obj, i64 %arg, i64 %l1, i64 %l2) {
entry:
%resolveCall = inttoptr i64 -559038737 to i8*
Grow the stackmap/patchpoint format to hold 64-bit IDs. llvm-svn: 197255
2013-12-14 02:37:10 +08:00
%result = call i64 (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.i64(i64 8, i32 15, i8* %resolveCall, i32 2, i64* %obj, i64 %arg, i64 %l1, i64 %l2)
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
%add = add i64 %result, 3
ret i64 %add
}
; Spilled stack map values.
;
; Verify 17 stack map entries.
;
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
2013-12-14 14:53:06 +08:00
; CHECK-LABEL: .long L{{.*}}-_spilledValue
; CHECK-NEXT: .short 0
; CHECK-NEXT: .short 17
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
;
Simplify operand folding when rematerializing a load. We already know how to fold a reload from a frameindex without analyzing the load instruction. Generalize this to handle any frameindex load. This streamlines the logic for rematerializing loads from stack arguments. As a side effect, it allows stackmaps to record a stack argument location without spilling it. Verified no effect on codegen for llvm test-suite. llvm-svn: 194497
2013-11-13 02:06:12 +08:00
; Check that at least one is a spilled entry from RBP.
; Location: Indirect RBP + ...
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
2013-12-14 14:53:06 +08:00
; CHECK: .byte 3
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short 6
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
define void @spilledValue(i64 %arg0, i64 %arg1, i64 %arg2, i64 %arg3, i64 %arg4, i64 %l0, i64 %l1, i64 %l2, i64 %l3, i64 %l4, i64 %l5, i64 %l6, i64 %l7, i64 %l8, i64 %l9, i64 %l10, i64 %l11, i64 %l12, i64 %l13, i64 %l14, i64 %l15, i64 %l16) {
entry:
Grow the stackmap/patchpoint format to hold 64-bit IDs. llvm-svn: 197255
2013-12-14 02:37:10 +08:00
call void (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.void(i64 11, i32 15, i8* null, i32 5, i64 %arg0, i64 %arg1, i64 %arg2, i64 %arg3, i64 %arg4, i64 %l0, i64 %l1, i64 %l2, i64 %l3, i64 %l4, i64 %l5, i64 %l6, i64 %l7, i64 %l8, i64 %l9, i64 %l10, i64 %l11, i64 %l12, i64 %l13, i64 %l14, i64 %l15, i64 %l16)
Add support for stack map generation in the X86 backend. Originally implemented by Lang Hames. llvm-svn: 193811
2013-11-01 06:11:56 +08:00
ret void
}
Cleanup the stackmap operand folding code and fix a corner case. I still don't know how to refer to the fixed operands symbolically. I plan to look into it. llvm-svn: 194529
2013-11-13 06:58:39 +08:00
; Spilled stack map values.
;
; Verify 17 stack map entries.
;
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
2013-12-14 14:53:06 +08:00
; CHECK-LABEL: .long L{{.*}}-_spilledStackMapValue
; CHECK-NEXT: .short 0
; CHECK-NEXT: .short 17
Cleanup the stackmap operand folding code and fix a corner case. I still don't know how to refer to the fixed operands symbolically. I plan to look into it. llvm-svn: 194529
2013-11-13 06:58:39 +08:00
;
; Check that at least one is a spilled entry from RBP.
; Location: Indirect RBP + ...
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
2013-12-14 14:53:06 +08:00
; CHECK: .byte 3
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short 6
Cleanup the stackmap operand folding code and fix a corner case. I still don't know how to refer to the fixed operands symbolically. I plan to look into it. llvm-svn: 194529
2013-11-13 06:58:39 +08:00
define webkit_jscc void @spilledStackMapValue(i64 %l0, i64 %l1, i64 %l2, i64 %l3, i64 %l4, i64 %l5, i64 %l6, i64 %l7, i64 %l8, i64 %l9, i64 %l10, i64 %l11, i64 %l12, i64 %l13, i64 %l14, i64 %l15, i64 %l16) {
entry:
Grow the stackmap/patchpoint format to hold 64-bit IDs. llvm-svn: 197255
2013-12-14 02:37:10 +08:00
call void (i64, i32, ...)* @llvm.experimental.stackmap(i64 12, i32 15, i64 %l0, i64 %l1, i64 %l2, i64 %l3, i64 %l4, i64 %l5, i64 %l6, i64 %l7, i64 %l8, i64 %l9, i64 %l10, i64 %l11, i64 %l12, i64 %l13, i64 %l14, i64 %l15, i64 %l16)
Cleanup the stackmap operand folding code and fix a corner case. I still don't know how to refer to the fixed operands symbolically. I plan to look into it. llvm-svn: 194529
2013-11-13 06:58:39 +08:00
ret void
}
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; Spill a subregister stackmap operand.
;
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
2013-12-14 14:53:06 +08:00
; CHECK-LABEL: .long L{{.*}}-_spillSubReg
; CHECK-NEXT: .short 0
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; 4 locations
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
2013-12-14 14:53:06 +08:00
; CHECK-NEXT: .short 1
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
;
; Check that the subregister operand is a 4-byte spill.
; Location: Indirect, 4-byte, RBP + ...
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
2013-12-14 14:53:06 +08:00
; CHECK: .byte 3
; CHECK-NEXT: .byte 4
; CHECK-NEXT: .short 6
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
define void @spillSubReg(i64 %arg) #0 {
bb:
br i1 undef, label %bb1, label %bb2
bb1:
unreachable
bb2:
%tmp = load i64* inttoptr (i64 140685446136880 to i64*)
br i1 undef, label %bb16, label %bb17
bb16:
unreachable
bb17:
%tmp32 = trunc i64 %tmp to i32
br i1 undef, label %bb60, label %bb61
bb60:
tail call void asm sideeffect "nop", "~{ax},~{bx},~{cx},~{dx},~{bp},~{si},~{di},~{r8},~{r9},~{r10},~{r11},~{r12},~{r13},~{r14},~{r15}"() nounwind
Grow the stackmap/patchpoint format to hold 64-bit IDs. llvm-svn: 197255
2013-12-14 02:37:10 +08:00
tail call void (i64, i32, ...)* @llvm.experimental.stackmap(i64 13, i32 5, i32 %tmp32)
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
unreachable
bb61:
unreachable
}
; Map a single byte subregister. There is no DWARF register number, so
; we expect the register to be encoded with the proper size and spill offset. We don't know which
;
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
2013-12-14 14:53:06 +08:00
; CHECK-LABEL: .long L{{.*}}-_subRegOffset
; CHECK-NEXT: .short 0
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
; 2 locations
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
2013-12-14 14:53:06 +08:00
; CHECK-NEXT: .short 2
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
;
; Check that the subregister operands are 1-byte spills.
; Location 0: Register, 4-byte, AL
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
2013-12-14 14:53:06 +08:00
; CHECK-NEXT: .byte 1
; CHECK-NEXT: .byte 1
; CHECK-NEXT: .short 0
; CHECK-NEXT: .long 0
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
;
; Location 1: Register, 4-byte, BL
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
2013-12-14 14:53:06 +08:00
; CHECK-NEXT: .byte 1
; CHECK-NEXT: .byte 1
; CHECK-NEXT: .short 3
; CHECK-NEXT: .long 0
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
define void @subRegOffset(i16 %arg) {
%v = mul i16 %arg, 5
%a0 = trunc i16 %v to i8
tail call void asm sideeffect "nop", "~{bx}"() nounwind
%arghi = lshr i16 %v, 8
%a1 = trunc i16 %arghi to i8
tail call void asm sideeffect "nop", "~{cx},~{dx},~{bp},~{si},~{di},~{r8},~{r9},~{r10},~{r11},~{r12},~{r13},~{r14},~{r15}"() nounwind
Grow the stackmap/patchpoint format to hold 64-bit IDs. llvm-svn: 197255
2013-12-14 02:37:10 +08:00
tail call void (i64, i32, ...)* @llvm.experimental.stackmap(i64 14, i32 5, i8 %a0, i8 %a1)
Added a size field to the stack map record to handle subregister spills. Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
2013-11-17 09:36:23 +08:00
ret void
}
patchpoint: factor SD builder code for live vars. Plain stackmap also optimizes Constant values now. llvm-svn: 195488
2013-11-23 03:07:36 +08:00
; Map a constant value.
;
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
2013-12-14 14:53:06 +08:00
; CHECK-LABEL: .long L{{.*}}-_liveConstant
; CHECK-NEXT: .short 0
patchpoint: factor SD builder code for live vars. Plain stackmap also optimizes Constant values now. llvm-svn: 195488
2013-11-23 03:07:36 +08:00
; 1 location
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
2013-12-14 14:53:06 +08:00
; CHECK-NEXT: .short 1
patchpoint: factor SD builder code for live vars. Plain stackmap also optimizes Constant values now. llvm-svn: 195488
2013-11-23 03:07:36 +08:00
; Loc 0: SmallConstant
; CHECK-NEXT: .byte 4
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short 0
; CHECK-NEXT: .long 33
define void @liveConstant() {
Grow the stackmap/patchpoint format to hold 64-bit IDs. llvm-svn: 197255
2013-12-14 02:37:10 +08:00
tail call void (i64, i32, ...)* @llvm.experimental.stackmap(i64 15, i32 5, i32 33)
patchpoint: factor SD builder code for live vars. Plain stackmap also optimizes Constant values now. llvm-svn: 195488
2013-11-23 03:07:36 +08:00
ret void
}
StackMap: Implement support for DirectMemRefOp. A Direct stack map location records the address of frame index. This address is itself the value that the runtime requested. This differs from IndirectMemRefOp locations, which refer to a stack locations from which the requested values must be loaded. Direct locations can directly communicate the address if an alloca, while IndirectMemRefOp handle register spills. For example: entry: %a = alloca i64... llvm.experimental.stackmap(i32 <ID>, i32 <shadowBytes>, i64* %a) Since both the alloca and stackmap intrinsic are in the entry block, and the intrinsic takes the address of the alloca, the runtime can assume that LLVM will not substitute alloca with any intervening value. This must be verified by the runtime by checking that the stack map's location is a Direct location type. The runtime can then determine the alloca's relative location on the stack immediately after compilation, or at any time thereafter. This differs from Register and Indirect locations, because the runtime can only read the values in those locations when execution reaches the instruction address of the stack map. llvm-svn: 195712
2013-11-26 10:03:25 +08:00
; Directly map an alloca's address.
;
; Callsite 16
; CHECK-LABEL: .long L{{.*}}-_directFrameIdx
; CHECK-NEXT: .short 0
; 1 location
; CHECK-NEXT: .short 1
; Loc 0: Direct RBP - ofs
; CHECK-NEXT: .byte 2
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short 6
; CHECK-NEXT: .long
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
2013-12-14 14:53:06 +08:00
StackMap: Implement support for DirectMemRefOp. A Direct stack map location records the address of frame index. This address is itself the value that the runtime requested. This differs from IndirectMemRefOp locations, which refer to a stack locations from which the requested values must be loaded. Direct locations can directly communicate the address if an alloca, while IndirectMemRefOp handle register spills. For example: entry: %a = alloca i64... llvm.experimental.stackmap(i32 <ID>, i32 <shadowBytes>, i64* %a) Since both the alloca and stackmap intrinsic are in the entry block, and the intrinsic takes the address of the alloca, the runtime can assume that LLVM will not substitute alloca with any intervening value. This must be verified by the runtime by checking that the stack map's location is a Direct location type. The runtime can then determine the alloca's relative location on the stack immediately after compilation, or at any time thereafter. This differs from Register and Indirect locations, because the runtime can only read the values in those locations when execution reaches the instruction address of the stack map. llvm-svn: 195712
2013-11-26 10:03:25 +08:00
; Callsite 17
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
2013-12-14 14:53:06 +08:00
; CHECK-LABEL: .long L{{.*}}-_directFrameIdx
StackMap: Implement support for DirectMemRefOp. A Direct stack map location records the address of frame index. This address is itself the value that the runtime requested. This differs from IndirectMemRefOp locations, which refer to a stack locations from which the requested values must be loaded. Direct locations can directly communicate the address if an alloca, while IndirectMemRefOp handle register spills. For example: entry: %a = alloca i64... llvm.experimental.stackmap(i32 <ID>, i32 <shadowBytes>, i64* %a) Since both the alloca and stackmap intrinsic are in the entry block, and the intrinsic takes the address of the alloca, the runtime can assume that LLVM will not substitute alloca with any intervening value. This must be verified by the runtime by checking that the stack map's location is a Direct location type. The runtime can then determine the alloca's relative location on the stack immediately after compilation, or at any time thereafter. This differs from Register and Indirect locations, because the runtime can only read the values in those locations when execution reaches the instruction address of the stack map. llvm-svn: 195712
2013-11-26 10:03:25 +08:00
; CHECK-NEXT: .short 0
; 2 locations
; CHECK-NEXT: .short 2
; Loc 0: Direct RBP - ofs
; CHECK-NEXT: .byte 2
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short 6
; CHECK-NEXT: .long
; Loc 1: Direct RBP - ofs
; CHECK-NEXT: .byte 2
; CHECK-NEXT: .byte 8
; CHECK-NEXT: .short 6
; CHECK-NEXT: .long
define void @directFrameIdx() {
entry:
%metadata1 = alloca i64, i32 3, align 8
store i64 11, i64* %metadata1
store i64 12, i64* %metadata1
store i64 13, i64* %metadata1
Grow the stackmap/patchpoint format to hold 64-bit IDs. llvm-svn: 197255
2013-12-14 02:37:10 +08:00
call void (i64, i32, ...)* @llvm.experimental.stackmap(i64 16, i32 0, i64* %metadata1)
StackMap: Implement support for DirectMemRefOp. A Direct stack map location records the address of frame index. This address is itself the value that the runtime requested. This differs from IndirectMemRefOp locations, which refer to a stack locations from which the requested values must be loaded. Direct locations can directly communicate the address if an alloca, while IndirectMemRefOp handle register spills. For example: entry: %a = alloca i64... llvm.experimental.stackmap(i32 <ID>, i32 <shadowBytes>, i64* %a) Since both the alloca and stackmap intrinsic are in the entry block, and the intrinsic takes the address of the alloca, the runtime can assume that LLVM will not substitute alloca with any intervening value. This must be verified by the runtime by checking that the stack map's location is a Direct location type. The runtime can then determine the alloca's relative location on the stack immediately after compilation, or at any time thereafter. This differs from Register and Indirect locations, because the runtime can only read the values in those locations when execution reaches the instruction address of the stack map. llvm-svn: 195712
2013-11-26 10:03:25 +08:00
%metadata2 = alloca i8, i32 4, align 8
%metadata3 = alloca i16, i32 4, align 8
Grow the stackmap/patchpoint format to hold 64-bit IDs. llvm-svn: 197255
2013-12-14 02:37:10 +08:00
call void (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.void(i64 17, i32 5, i8* null, i32 0, i8* %metadata2, i16* %metadata3)
ret void
}
; Test a 64-bit ID.
;
; CHECK: .quad 4294967295
; CHECK-LABEL: .long L{{.*}}-_longid
; CHECK: .quad 4294967296
; CHECK-LABEL: .long L{{.*}}-_longid
; CHECK: .quad 9223372036854775807
; CHECK-LABEL: .long L{{.*}}-_longid
; CHECK: .quad -1
; CHECK-LABEL: .long L{{.*}}-_longid
define void @longid() {
entry:
tail call void (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.void(i64 4294967295, i32 0, i8* null, i32 0)
tail call void (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.void(i64 4294967296, i32 0, i8* null, i32 0)
tail call void (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.void(i64 9223372036854775807, i32 0, i8* null, i32 0)
tail call void (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.void(i64 -1, i32 0, i8* null, i32 0)
StackMap: Implement support for DirectMemRefOp. A Direct stack map location records the address of frame index. This address is itself the value that the runtime requested. This differs from IndirectMemRefOp locations, which refer to a stack locations from which the requested values must be loaded. Direct locations can directly communicate the address if an alloca, while IndirectMemRefOp handle register spills. For example: entry: %a = alloca i64... llvm.experimental.stackmap(i32 <ID>, i32 <shadowBytes>, i64* %a) Since both the alloca and stackmap intrinsic are in the entry block, and the intrinsic takes the address of the alloca, the runtime can assume that LLVM will not substitute alloca with any intervening value. This must be verified by the runtime by checking that the stack map's location is a Direct location type. The runtime can then determine the alloca's relative location on the stack immediately after compilation, or at any time thereafter. This differs from Register and Indirect locations, because the runtime can only read the values in those locations when execution reaches the instruction address of the stack map. llvm-svn: 195712
2013-11-26 10:03:25 +08:00
ret void
}
Make stackmap machineinstrs clobber the scratch regs too. Patchpoints already did this. Doing it for stackmaps is a convenience for the runtime in the event that it needs to scratch register to patch or perform a runtime call thunk. Unlike patchpoints, we just assume the AnyRegCC calling convention. This is the only language and target independent calling convention specific to stackmaps so makes sense. Although the calling convention is not currently used to select the scratch registers. llvm-svn: 202943
2014-03-05 15:08:16 +08:00
; Map a value when R11 is the only free register.
; The scratch register should not be used for a live stackmap value.
;
; CHECK-LABEL: .long L{{.*}}-_clobberScratch
; CHECK-NEXT: .short 0
; 1 location
; CHECK-NEXT: .short 1
; Loc 0: Indirect fp - offset
; CHECK-NEXT: .byte 3
; CHECK-NEXT: .byte 4
; CHECK-NEXT: .short 6
; CHECK-NEXT: .long -{{[0-9]+}}
define void @clobberScratch(i32 %a) {
tail call void asm sideeffect "nop", "~{ax},~{bx},~{cx},~{dx},~{bp},~{si},~{di},~{r8},~{r9},~{r10},~{r12},~{r13},~{r14},~{r15}"() nounwind
tail call void (i64, i32, ...)* @llvm.experimental.stackmap(i64 16, i32 8, i32 %a)
ret void
}
Grow the stackmap/patchpoint format to hold 64-bit IDs. llvm-svn: 197255
2013-12-14 02:37:10 +08:00
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, ...)