2016-02-16 07:44:13 +08:00
|
|
|
; RUN: llc < %s -stack-symbol-ordering=0 -mtriple="x86_64-pc-linux-gnu" | FileCheck %s
|
|
|
|
; RUN: llc < %s -stack-symbol-ordering=0 -mtriple="x86_64-pc-unknown-elf" | FileCheck %s
|
2015-06-25 08:28:42 +08:00
|
|
|
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
; This test is a sanity check to ensure statepoints are generating StackMap
|
|
|
|
; sections correctly. This is not intended to be a rigorous test of the
|
|
|
|
; StackMap format (see the stackmap tests for that).
|
|
|
|
|
|
|
|
target datalayout = "e-i64:64-f80:128-n8:16:32:64-S128"
|
|
|
|
|
|
|
|
declare zeroext i1 @return_i1()
|
|
|
|
|
2015-05-12 21:12:14 +08:00
|
|
|
define i1 @test(i32 addrspace(1)* %ptr_base, i32 %arg)
|
|
|
|
gc "statepoint-example" {
|
2015-12-24 07:44:28 +08:00
|
|
|
; CHECK-LABEL: test:
|
2015-05-12 21:12:14 +08:00
|
|
|
; Do we see two spills for the local values and the store to the
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
; alloca?
|
2015-05-12 21:12:14 +08:00
|
|
|
; CHECK: subq $40, %rsp
|
|
|
|
; CHECK: movq $0, 24(%rsp)
|
|
|
|
; CHECK: movq %rdi, 16(%rsp)
|
|
|
|
; CHECK: movq %rax, 8(%rsp)
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
; CHECK: callq return_i1
|
2015-05-12 21:12:14 +08:00
|
|
|
; CHECK: addq $40, %rsp
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
; CHECK: retq
|
|
|
|
entry:
|
|
|
|
%metadata1 = alloca i32 addrspace(1)*, i32 2, align 8
|
|
|
|
store i32 addrspace(1)* null, i32 addrspace(1)** %metadata1
|
2015-05-12 21:12:14 +08:00
|
|
|
%ptr_derived = getelementptr i32, i32 addrspace(1)* %ptr_base, i32 %arg
|
2015-12-26 15:54:32 +08:00
|
|
|
%safepoint_token = tail call token (i64, i32, i1 ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_i1f(i64 0, i32 0, i1 ()* @return_i1, i32 0, i32 0, i32 0, i32 2, i32 addrspace(1)* %ptr_base, i32 addrspace(1)* null, i32 addrspace(1)* %ptr_base, i32 addrspace(1)* %ptr_derived, i32 addrspace(1)* null)
|
|
|
|
%call1 = call zeroext i1 @llvm.experimental.gc.result.i1(token %safepoint_token)
|
|
|
|
%a = call i32 addrspace(1)* @llvm.experimental.gc.relocate.p1i32(token %safepoint_token, i32 9, i32 9)
|
|
|
|
%b = call i32 addrspace(1)* @llvm.experimental.gc.relocate.p1i32(token %safepoint_token, i32 9, i32 10)
|
|
|
|
%c = call i32 addrspace(1)* @llvm.experimental.gc.relocate.p1i32(token %safepoint_token, i32 11, i32 11)
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
;
|
|
|
|
ret i1 %call1
|
|
|
|
}
|
|
|
|
|
2015-05-12 21:12:14 +08:00
|
|
|
; This is similar to the previous test except that we have derived pointer as
|
|
|
|
; argument to the function. Despite that this can not happen after the
|
|
|
|
; RewriteSafepointForGC pass, lowering should be able to handle it anyway.
|
|
|
|
define i1 @test_derived_arg(i32 addrspace(1)* %ptr_base,
|
|
|
|
i32 addrspace(1)* %ptr_derived)
|
|
|
|
gc "statepoint-example" {
|
|
|
|
; CHECK-LABEL: test_derived_arg
|
|
|
|
; Do we see two spills for the local values and the store to the
|
|
|
|
; alloca?
|
|
|
|
; CHECK: subq $40, %rsp
|
|
|
|
; CHECK: movq $0, 24(%rsp)
|
|
|
|
; CHECK: movq %rdi, 16(%rsp)
|
|
|
|
; CHECK: movq %rsi, 8(%rsp)
|
|
|
|
; CHECK: callq return_i1
|
|
|
|
; CHECK: addq $40, %rsp
|
|
|
|
; CHECK: retq
|
|
|
|
entry:
|
|
|
|
%metadata1 = alloca i32 addrspace(1)*, i32 2, align 8
|
|
|
|
store i32 addrspace(1)* null, i32 addrspace(1)** %metadata1
|
2015-12-26 15:54:32 +08:00
|
|
|
%safepoint_token = tail call token (i64, i32, i1 ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_i1f(i64 0, i32 0, i1 ()* @return_i1, i32 0, i32 0, i32 0, i32 2, i32 addrspace(1)* %ptr_base, i32 addrspace(1)* null, i32 addrspace(1)* %ptr_base, i32 addrspace(1)* %ptr_derived, i32 addrspace(1)* null)
|
|
|
|
%call1 = call zeroext i1 @llvm.experimental.gc.result.i1(token %safepoint_token)
|
|
|
|
%a = call i32 addrspace(1)* @llvm.experimental.gc.relocate.p1i32(token %safepoint_token, i32 9, i32 9)
|
|
|
|
%b = call i32 addrspace(1)* @llvm.experimental.gc.relocate.p1i32(token %safepoint_token, i32 9, i32 10)
|
|
|
|
%c = call i32 addrspace(1)* @llvm.experimental.gc.relocate.p1i32(token %safepoint_token, i32 11, i32 11)
|
2015-05-12 21:12:14 +08:00
|
|
|
;
|
|
|
|
ret i1 %call1
|
|
|
|
}
|
|
|
|
|
2015-05-13 07:52:24 +08:00
|
|
|
; Simple test case to check that we emit the ID field correctly
|
|
|
|
define i1 @test_id() gc "statepoint-example" {
|
|
|
|
; CHECK-LABEL: test_id
|
|
|
|
entry:
|
2015-12-26 15:54:32 +08:00
|
|
|
%safepoint_token = tail call token (i64, i32, i1 ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_i1f(i64 237, i32 0, i1 ()* @return_i1, i32 0, i32 0, i32 0, i32 0)
|
|
|
|
%call1 = call zeroext i1 @llvm.experimental.gc.result.i1(token %safepoint_token)
|
2015-05-13 07:52:24 +08:00
|
|
|
ret i1 %call1
|
|
|
|
}
|
2015-05-12 21:12:14 +08:00
|
|
|
|
2015-05-13 07:52:24 +08:00
|
|
|
|
2015-12-26 15:54:32 +08:00
|
|
|
declare token @llvm.experimental.gc.statepoint.p0f_i1f(i64, i32, i1 ()*, i32, i32, ...)
|
|
|
|
declare i1 @llvm.experimental.gc.result.i1(token)
|
|
|
|
declare i32 addrspace(1)* @llvm.experimental.gc.relocate.p1i32(token, i32, i32) #3
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
|
|
|
|
; CHECK-LABEL: .section .llvm_stackmaps
|
|
|
|
; CHECK-NEXT: __LLVM_StackMaps:
|
|
|
|
; Header
|
2016-09-15 04:22:03 +08:00
|
|
|
; CHECK-NEXT: .byte 2
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
; CHECK-NEXT: .byte 0
|
|
|
|
; CHECK-NEXT: .short 0
|
|
|
|
; Num Functions
|
2015-05-13 07:52:24 +08:00
|
|
|
; CHECK-NEXT: .long 3
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
; Num LargeConstants
|
|
|
|
; CHECK-NEXT: .long 0
|
|
|
|
; Num Callsites
|
2015-05-13 07:52:24 +08:00
|
|
|
; CHECK-NEXT: .long 3
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
|
|
|
|
; Functions and stack size
|
|
|
|
; CHECK-NEXT: .quad test
|
2015-05-12 21:12:14 +08:00
|
|
|
; CHECK-NEXT: .quad 40
|
2016-09-15 04:22:03 +08:00
|
|
|
; CHECK-NEXT: .quad 1
|
2015-05-12 21:12:14 +08:00
|
|
|
; CHECK-NEXT: .quad test_derived_arg
|
|
|
|
; CHECK-NEXT: .quad 40
|
2016-09-15 04:22:03 +08:00
|
|
|
; CHECK-NEXT: .quad 1
|
2015-12-24 07:44:28 +08:00
|
|
|
; CHECK-NEXT: .quad test_id
|
|
|
|
; CHECK-NEXT: .quad 8
|
2016-09-15 04:22:03 +08:00
|
|
|
; CHECK-NEXT: .quad 1
|
2015-05-12 21:12:14 +08:00
|
|
|
|
|
|
|
;
|
|
|
|
; test
|
|
|
|
;
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
|
2015-12-24 07:44:28 +08:00
|
|
|
; Statepoint ID
|
|
|
|
; CHECK-NEXT: .quad 0
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
|
|
|
|
; Callsites
|
|
|
|
; Constant arguments
|
2016-12-01 07:48:26 +08:00
|
|
|
; CHECK-NEXT: .long .Ltmp0-test
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
; CHECK: .short 0
|
2015-05-13 03:50:19 +08:00
|
|
|
; CHECK: .short 11
|
|
|
|
; SmallConstant (0)
|
|
|
|
; CHECK: .byte 4
|
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 0
|
|
|
|
; CHECK: .long 0
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
; SmallConstant (0)
|
|
|
|
; CHECK: .byte 4
|
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 0
|
|
|
|
; CHECK: .long 0
|
|
|
|
; SmallConstant (2)
|
|
|
|
; CHECK: .byte 4
|
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 0
|
|
|
|
; CHECK: .long 2
|
2015-12-24 07:44:28 +08:00
|
|
|
; Indirect Spill Slot [RSP+0]
|
|
|
|
; CHECK: .byte 3
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 7
|
2015-05-12 21:12:14 +08:00
|
|
|
; CHECK: .long 16
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
; SmallConstant (0)
|
|
|
|
; CHECK: .byte 4
|
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 0
|
|
|
|
; CHECK: .long 0
|
|
|
|
; SmallConstant (0)
|
|
|
|
; CHECK: .byte 4
|
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 0
|
|
|
|
; CHECK: .long 0
|
|
|
|
; SmallConstant (0)
|
|
|
|
; CHECK: .byte 4
|
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 0
|
|
|
|
; CHECK: .long 0
|
2015-12-24 07:44:28 +08:00
|
|
|
; Indirect Spill Slot [RSP+16]
|
|
|
|
; CHECK: .byte 3
|
2015-05-12 21:12:14 +08:00
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 7
|
|
|
|
; CHECK: .long 16
|
2015-12-24 07:44:28 +08:00
|
|
|
; Indirect Spill Slot [RSP+8]
|
|
|
|
; CHECK: .byte 3
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 7
|
2015-05-12 21:12:14 +08:00
|
|
|
; CHECK: .long 8
|
2015-12-24 07:44:28 +08:00
|
|
|
; Indirect Spill Slot [RSP+16]
|
|
|
|
; CHECK: .byte 3
|
2015-05-12 21:12:14 +08:00
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 7
|
|
|
|
; CHECK: .long 16
|
2015-12-24 07:44:28 +08:00
|
|
|
; Indirect Spill Slot [RSP+16]
|
|
|
|
; CHECK: .byte 3
|
2015-05-12 21:12:14 +08:00
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 7
|
|
|
|
; CHECK: .long 16
|
|
|
|
|
|
|
|
; No Padding or LiveOuts
|
|
|
|
; CHECK: .short 0
|
|
|
|
; CHECK: .short 0
|
2016-01-26 08:03:25 +08:00
|
|
|
; CHECK: .p2align 3
|
2015-05-12 21:12:14 +08:00
|
|
|
|
|
|
|
;
|
|
|
|
; test_derived_arg
|
|
|
|
|
2015-12-24 07:44:28 +08:00
|
|
|
; Statepoint ID
|
|
|
|
; CHECK-NEXT: .quad 0
|
2015-05-12 21:12:14 +08:00
|
|
|
|
|
|
|
; Callsites
|
|
|
|
; Constant arguments
|
2016-12-01 07:48:26 +08:00
|
|
|
; CHECK-NEXT: .long .Ltmp1-test_derived_arg
|
2015-05-12 21:12:14 +08:00
|
|
|
; CHECK: .short 0
|
2015-05-13 03:50:19 +08:00
|
|
|
; CHECK: .short 11
|
2015-05-12 21:12:14 +08:00
|
|
|
; SmallConstant (0)
|
|
|
|
; CHECK: .byte 4
|
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 0
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
; CHECK: .long 0
|
2015-05-12 21:12:14 +08:00
|
|
|
; SmallConstant (2)
|
|
|
|
; CHECK: .byte 4
|
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 0
|
|
|
|
; CHECK: .long 2
|
2015-12-24 07:44:28 +08:00
|
|
|
; Indirect Spill Slot [RSP+0]
|
|
|
|
; CHECK: .byte 3
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 7
|
2015-05-12 21:12:14 +08:00
|
|
|
; CHECK: .long 16
|
|
|
|
; SmallConstant (0)
|
|
|
|
; CHECK: .byte 4
|
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 0
|
|
|
|
; CHECK: .long 0
|
|
|
|
; SmallConstant (0)
|
|
|
|
; CHECK: .byte 4
|
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 0
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
; CHECK: .long 0
|
2015-05-12 21:12:14 +08:00
|
|
|
; SmallConstant (0)
|
|
|
|
; CHECK: .byte 4
|
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 0
|
|
|
|
; CHECK: .long 0
|
2015-12-24 07:44:28 +08:00
|
|
|
; Indirect Spill Slot [RSP+16]
|
|
|
|
; CHECK: .byte 3
|
2015-05-12 21:12:14 +08:00
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 7
|
|
|
|
; CHECK: .long 16
|
2015-12-24 07:44:28 +08:00
|
|
|
; Indirect Spill Slot [RSP+8]
|
|
|
|
; CHECK: .byte 3
|
2015-05-12 21:12:14 +08:00
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 7
|
|
|
|
; CHECK: .long 8
|
2015-12-24 07:44:28 +08:00
|
|
|
; Indirect Spill Slot [RSP+16]
|
|
|
|
; CHECK: .byte 3
|
2015-05-12 21:12:14 +08:00
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 7
|
|
|
|
; CHECK: .long 16
|
2015-12-24 07:44:28 +08:00
|
|
|
; Indirect Spill Slot [RSP+16]
|
|
|
|
; CHECK: .byte 3
|
2015-05-12 21:12:14 +08:00
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 7
|
|
|
|
; CHECK: .long 16
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
|
|
|
|
; No Padding or LiveOuts
|
|
|
|
; CHECK: .short 0
|
|
|
|
; CHECK: .short 0
|
2016-01-26 08:03:25 +08:00
|
|
|
; CHECK: .p2align 3
|
2015-05-13 07:52:24 +08:00
|
|
|
|
|
|
|
; Records for the test_id function:
|
|
|
|
|
|
|
|
; The Statepoint ID:
|
2015-12-24 07:44:28 +08:00
|
|
|
; CHECK-NEXT: .quad 237
|
2015-05-13 07:52:24 +08:00
|
|
|
|
|
|
|
; Instruction Offset
|
2016-12-01 07:48:26 +08:00
|
|
|
; CHECK-NEXT: .long .Ltmp2-test_id
|
2015-05-13 07:52:24 +08:00
|
|
|
|
|
|
|
; Reserved:
|
|
|
|
; CHECK: .short 0
|
|
|
|
|
|
|
|
; NumLocations:
|
|
|
|
; CHECK: .short 3
|
|
|
|
|
|
|
|
; StkMapRecord[0]:
|
|
|
|
; SmallConstant(0):
|
|
|
|
; CHECK: .byte 4
|
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 0
|
|
|
|
; CHECK: .long 0
|
|
|
|
|
|
|
|
; StkMapRecord[1]:
|
|
|
|
; SmallConstant(0):
|
|
|
|
; CHECK: .byte 4
|
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 0
|
|
|
|
; CHECK: .long 0
|
|
|
|
|
|
|
|
; StkMapRecord[2]:
|
|
|
|
; SmallConstant(0):
|
|
|
|
; CHECK: .byte 4
|
|
|
|
; CHECK: .byte 8
|
|
|
|
; CHECK: .short 0
|
|
|
|
; CHECK: .long 0
|
|
|
|
|
|
|
|
; No padding or LiveOuts
|
|
|
|
; CHECK: .short 0
|
|
|
|
; CHECK: .short 0
|
2016-01-26 08:03:25 +08:00
|
|
|
; CHECK: .p2align 3
|