Page MenuHomePhabricator

[Statepoints] Use Indirect operands for spill slots
ClosedPublic

Authored by reames on Dec 23 2015, 2:12 PM.

Details

Summary

Teach the statepoint lowering code to emit Indirect stackmap entries for spill inserted by StatepointLowering (i.e. SelectionDAG), but Direct stackmap entries for in-IR allocas which represent manual stack slots. This is what the docs call for (http://llvm.org/docs/StackMaps.html#stack-map-format), but we've been emitting both as Direct. This was pointed out recently on the mailing list as a bug. It also blocks http://reviews.llvm.org/D15632 which extends the lowering to handle vector-of-pointers since only Indirect references can encode a variable sized slot.

To implement this, I introduced a new flag on the StackObject class used to maintian information about stack slots. I original considered (and prototyped in http://reviews.llvm.org/D15632), the idea of using the existing isSpillSlot flag, but end up deciding that was a bit too risky and that the cost of adding a new flag was low. Having the new flag will also allow us - in the future - to emit better comments in verbose assembly which indicate where a particular stack spill around a call comes from. (deopt, gc, regalloc).

Diff Detail

Repository
rL LLVM

Event Timeline

reames updated this revision to Diff 43557.Dec 23 2015, 2:12 PM
reames retitled this revision from to [Statepoints] Use Indirect operands for spill slots.
reames updated this object.
reames added a subscriber: llvm-commits.
atrick accepted this revision.Dec 23 2015, 2:19 PM
atrick edited edge metadata.

It's good that you use the right StackMap tags to be consistent with PatchPoints. Hopefully you can stop spilling your StatePoint values eventually.

This revision is now accepted and ready to land.Dec 23 2015, 2:19 PM

Hopefully you can stop spilling your StatePoint values eventually.

This is still on the eventual todo list and some of the recent changes to the register allocator make it look a lot more straightforward than it used to be. Somewhat suprisingly, we've found this to be an utter non-issue performance wise, so it's hard to justify spending a lot of time on it. (The general issue is that any call which has hot spills is one we really should have inlined. Once we fix the inlining, which we'd want to do anyway, the spills disappear.)

This revision was automatically updated to reflect the committed changes.