OSDN Git Service

[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
authorPhilip Reames <listmail@philipreames.com>
Tue, 2 Dec 2014 18:50:36 +0000 (18:50 +0000)
committerPhilip Reames <listmail@philipreames.com>
Tue, 2 Dec 2014 18:50:36 +0000 (18:50 +0000)
commitd021bb800384f577fbaed4ce25381161af21e2dd
tree4eb7c21bec7fee4f9b36e59d9473822bb3916d22
parent495e547ef978d323679d5f535f7c0b5bad359b12
[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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223137 91177308-0d34-0410-b5e6-96231b3b80d8
14 files changed:
include/llvm/CodeGen/FunctionLoweringInfo.h
include/llvm/IR/Statepoint.h [new file with mode: 0644]
lib/CodeGen/SelectionDAG/CMakeLists.txt
lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp
lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
lib/CodeGen/SelectionDAG/SelectionDAGBuilder.h
lib/CodeGen/SelectionDAG/StatepointLowering.cpp [new file with mode: 0644]
lib/CodeGen/SelectionDAG/StatepointLowering.h [new file with mode: 0644]
lib/IR/CMakeLists.txt
lib/IR/Statepoint.cpp [new file with mode: 0644]
lib/Transforms/InstCombine/InstCombineCalls.cpp
test/CodeGen/X86/statepoint-call-lowering.ll [new file with mode: 0644]
test/CodeGen/X86/statepoint-stack-usage.ll [new file with mode: 0644]
test/CodeGen/X86/statepoint-stackmap-format.ll [new file with mode: 0644]