[LLVMdev] Adding a custom GC safe point creation phase

[Nicolas Geoffray]

Thanks for the review Gordon.

On Tue, Nov 1, 2011 at 2:21 AM, Gordon Henriksen <gordonhenriksen at mac.com>wrote:

> On 2011-10-31, at 17:21, Nicolas Geoffray wrote:
>
> > Here's a patch to allow a GCStrategy to customize the places where it
> wants to insert safe points. I'm not sure who maintains the GC code today
> in LLVM (I'd be happy to take ownership, if needed).
> >
> > The patch just adds up a custom safepoints flag, similar to the way the
> GCStrategy can customize intrinsics lowering, or roots initialization. It
> works pretty well, as I've tested it on VMKit. So the patch in itself
> should not be controversial.
>
> Seems a perfectly reasonable patch on its own merits.
>
> I would be curious what your findCustomSafePoints implementation looks
> like. Perhaps it's possible to extract some of it into the framework.
>

The code for my findCustomSafePoints is like this:

void MyGC::findCustomSafePoints(GCFunctionInfo& FI, MachineFunction &MF) {
  for (MachineFunction::iterator BBI = MF.begin(),
                                 BBE = MF.end(); BBI != BBE; ++BBI) {
    for (MachineBasicBlock::iterator MI = BBI->begin(),
                                     ME = BBI->end(); MI != ME; ++MI) {
      if (MI->getDesc().isCall()) {
               /// Standard code need for adding a post call safe point;
      } else if (MI->getDebucLoc().getCol() == 1) {
              /// Standard code need for adding a post call safe point;
      }
  }
}

So it really looks like what we already have, except this special trick
about checking the debug location. Piggy backing on the debug location is
easy and works for me because:
1) Debug locations are passed from LLVM Instructions to MachineInstruction
2) I don't have column numbers in my front-end.

The instructions that get this special marker on the debug location are
instructions that may trigger a segmentation fault. Because I enter a
signal handler, that may invoke a collection, I need to know the roots at
the faulting instruction's address.


> > Chris, I'd like to discuss with you on how we can improve the current GC
> framework to take advantage of metadata. The reason I add this custom safe
> point creation method is because it's difficult for a front-end to pass
> custom information to the GC framework. And I think metadata could help us
> in this situation. Ideally, I'd like to get to a point where we can write:
> >
> > 15 = load %MyPointer* %2 !safepoint
> >
> > And the GCStrategy would find this metadata information in the
> MachineInstruction (because the safe points are created based on
> MachineInstruction). This solution looks very much like the !nontemporal
> metadata.
> >
> > Unfortunately, it looks like metadata are not passed down to
> MachineInstruction. How could we achieve that? Should we write custom code
> in the Instruction -> MachineInstruction transformation to pass down that
> !safepoint metadata?
>
> Could such a program survive IR optimizations intact?
>

Well, we must be sure that any instruction that is a safepoint does get
some metadata associated with it. If such instruction does not get this
metadata, then then program would not survive. So the 'safepoint' metadata
*must* be preserved across optimizations if the instruction gets emitted.

Nicolas


> — Gordon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111101/2b6766df/attachment.html>