<div dir="ltr">+Filip Pizlo</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 8, 2014 at 2:24 PM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi hfinkel, chandlerc, nicholas, sanjoy, atrick, ributzka, theraven,<br>
<br>
The attached patch implements an approach to supporting garbage collection in LLVM that has been mentioned on the mailing list a number of times by now. There's a couple of issues that need to be addressed before submission, but I wanted to get this up to give maximal time for review.<br>
<br>
The statepoint intrinsics are intended to enable precise root tracking through the compiler as to support garbage collectors of all types. Our testing to date has focused on fully relocating collectors (where pointers can change at any safepoint poll, or call site), but the infrastructure should support collectors of other styles. The addition of the statepoint intrinsics to LLVM should have no impact on the compilation of any program which does not contain them. There are no side tables created, no extra metadata, and no inhibited optimizations.<br>
<br>
A statepoint works by transforming a call site (or safepoint poll site) into an explicit relocation operation. It is the frontend's responsibility (or eventually the safepoint insertion pass we've developed, but that's not part of this patch) to ensure that any live pointer to a GC object is correctly added to the statepoint and explicitly relocated. The relocated value is just a normal SSA value (as seen by the optimizer), so merges of relocated and unrelocated values are just normal phis. The explicit relocation operation, the fact the statepoint is assumed to clobber all memory, and the optimizers standard semantics ensure that the relocations flow through IR optimizations correctly.<br>
<br>
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. We leverage the existing StackMap section format, which is already used by the patchpoint intrinsics, to report where pointer values live. Unlike a patchpoint, these locations are known (by the backend) to be writeable during the call. This enables the garbage collector to transparently read and update pointer values if required. We do optimize lowering in certain well known cases (constant pointers, a.k.a. null, being the key one.)<br>
<br>
There are a few areas of this patch which could use improvement:<br>
- The patch needs rebased against TOT. It's currently based against a roughly 3 week old snapshot.<br>
- The intrinsics should probably be renamed to include an "experimental" prefix.<br>
- The usage of Direct and Indirect location types are currently inverted as compared to the definition used by patchpoint. This is a simple fix.<br>
- The test coverage could be improved. Most of the tests we've actually been using are built on top of the safepoint insertion mechanism (not included here) and our runtime. We need to improve the IR level tests for optimizer semantics (i.e. not doing illegal transforms), and lowering. There are some minimal tests in place for the lowering of simple statepoints.<br>
- The documentation is "in progress" (to put it kindly.)<br>
- Many functions are missing doxygen comments<br>
- There's a hack in to force the use of RSP+Offset addressing vs RBP-Offset addressing for references in the StackMap section. This works, shouldn't break anyone else, but should definitely be cleaned up. The choice of addressing preference should be up to the runtime.<br>
<br>
When reviewing, I would greatly appreciate feedback on which issues need to be fixed before submission and those which can be addressed afterwards. It is my plan to actively maintain and enhance this infrastructure over next few months (and years). It's already been developed out of tree entirely too long (our fault!), and I'd like to move to incremental work in tree as quickly as feasible.<br>
<br>
Planned enhancements after submission:<br>
- The ordering of arguments in statepoints is essentially historical cruft at this point. I'm open to suggestions on how to make this more approachable. Reordering arguments would (preferably) be a post commit action.<br>
- Support for relocatable pointers in callee saved registers over call sites. This will require the notation of an explicit relocation psuedo op and support for it throughout the backend (particularly the register allocator.)<br>
- Optimizations for non-relocating collectors. For example, the clobber semantics of the spill slots aren't needed if the collector isn't relocating roots.<br>
- Further optimizations to reduce the cost of spilling around each statepoint (when required at all).<br>
- Support for invokable statepoints.<br>
- Once this has baked in tree for a while, I plan to delete the existing gc_root code. It is unsound, and essentially unused.<br>
<br>
In addition to the enhancements to the infrastructure in the currently proposed patch, we're also working on a number of follow up changes:<br>
- Verification passes to confirm that safepoints were inserted in a semantically valid way (i.e. no memory access of a value after it has been inserted)<br>
- A transformation pass to convert naive IR to include both safepoint polling sites, and statepoints on every non-leaf call. This transformation pass can be used at initial IR creation time to simplify the frontend authors' work, but is also designed to run on *fully optimized* IR, provided the initial IR meets certain (fairly loose) restrictions.<br>
- A transformation pass to convert normal loads and stores into user provided load and store barriers.<br>
- Further optimizations to reduce the number of safepoints required, and improve the infrastructure as a whole.<br>
<br>
We've been working on these topics for a while, but the follow on patches aren't quite as mature as what's being proposed now. Once these pieces stabilize a bit, we plan to upstream them as well. For those who are curious, our work on those topics is available here: <a href="https://github.com/AzulSystems/llvm-late-safepoint-placement" target="_blank">https://github.com/AzulSystems/llvm-late-safepoint-placement</a><br>
<br>
<a href="http://reviews.llvm.org/D5683" target="_blank">http://reviews.llvm.org/D5683</a><br>
<br>
Files:<br>
docs/Statepoints.rst<br>
include/llvm/CodeGen/FunctionLoweringInfo.h<br>
include/llvm/CodeGen/MachineInstr.h<br>
include/llvm/CodeGen/StackMaps.h<br>
include/llvm/IR/Intrinsics.td<br>
include/llvm/IR/Statepoint.h<br>
include/llvm/Target/Target.td<br>
include/llvm/Target/TargetFrameLowering.h<br>
include/llvm/Target/TargetOpcodes.h<br>
lib/Analysis/TargetTransformInfo.cpp<br>
lib/CodeGen/InlineSpiller.cpp<br>
lib/CodeGen/LocalStackSlotAllocation.cpp<br>
lib/CodeGen/PrologEpilogInserter.cpp<br>
lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp<br>
lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp<br>
lib/CodeGen/SelectionDAG/SelectionDAGBuilder.h<br>
lib/CodeGen/StackMaps.cpp<br>
lib/CodeGen/TargetLoweringBase.cpp<br>
lib/IR/CMakeLists.txt<br>
lib/IR/Function.cpp<br>
lib/IR/LLVMContext.cpp<br>
lib/IR/Statepoint.cpp<br>
lib/IR/Verifier.cpp<br>
lib/Target/X86/X86FrameLowering.cpp<br>
lib/Target/X86/X86FrameLowering.h<br>
lib/Target/X86/X86ISelLowering.cpp<br>
lib/Target/X86/X86MCInstLower.cpp<br>
lib/Transforms/InstCombine/InstCombineCalls.cpp<br>
test/CodeGen/X86/statepoint-call-lowering.ll<br>
test/CodeGen/X86/statepoint-stack-usage.ll<br>
test/CodeGen/X86/statepoint-stackmap-format.ll<br>
test/Verifier/statepoint-non-gc-ptr.ll<br>
test/Verifier/statepoint.ll<br>
utils/TableGen/CodeGenTarget.cpp<br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>