[PATCH] D15632: [GC][In Progress] Relocating vectors of pointers

[Philip Reames via llvm-commits]

reames created this revision.
reames added reviewers: qcolombet, JosephTremoulet, sanjoy, igor-laevsky, ributzka, pgavlin.
reames added a subscriber: llvm-commits.

(This patch is in progress.  There's a couple pieces that need fixed/split out - as commented - but I'm hoping to get feedback on the general approach.  Tests have not yet been updated.)

Currently, we try to split vectors of pointers back into their component pointer elements during rewrite-statepoints-for-gc.  This is less than ideal since presumably the vectorizer chose to vectorize for a reason.  :)  It's also been a source of bugs - in particular, the relocation logic as currently implemented was recently discovered to be wrong.  

The alternate approach is to allow gc.relocates of vector-of-pointer type and update the backend to handle them.  It turns out that's surprisingly easy, but it does force us to switch from Direct slots to Indirect slots so that we can represent the variable size of the slots.  Since we really should have been using those all along - i.e. we're out of sync with the docs - this doesn't seem like a bad thing to do.

Actually doing so is where the questions come up though.  Is it appropriate to have the statepoint lowering generate "spill slots" as used in MachineFrameInfo?  Currently, these only appear to be generated by the register allocator and I wasn't sure whether my usage here broke some subtle expectation in the backend.  The reason for wanting to do this is that I need to distinguish between the spill slots created by the lowering (which should be Indirect) and allocas explicitly passed to the statepoint (which should be Direct).  

Patchpoint solves this same issue by emitting everything as normal virtual registers and then letting the register allocator fold to Indirect if needed.  This approach doesn't work for statepoints today since the liveness requirements are different (live-through-call vs live-at-call) and the register allocator hasn't been taught to understand them.  


http://reviews.llvm.org/D15632

Files:
  include/llvm/CodeGen/SelectionDAG.h
  include/llvm/IR/Intrinsics.td
  lib/CodeGen/SelectionDAG/SelectionDAG.cpp
  lib/CodeGen/SelectionDAG/StatepointLowering.cpp
  lib/CodeGen/TargetLoweringBase.cpp
  lib/IR/Verifier.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D15632.43199.patch
Type: text/x-patch
Size: 8223 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151218/da0d6f22/attachment.bin>