Nicolas Geoffray
2011-Nov-01 08:47 UTC
[LLVMdev] Adding a custom GC safe point creation phase
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>
Gordon Henriksen
2011-Nov-01 09:48 UTC
[LLVMdev] Adding a custom GC safe point creation phase
On Nov 1, 2011, at 4:47 AM, Nicolas Geoffray <nicolas.geoffray at gmail.com> wrote:> 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.I have my doubts about the robustness of this strategy, but if it's working well enough for your needs, then great. Your patch seems appropriately factored. The alternative would seem to be calling a virtualized predicate on each machine instruction, as I don't think your debug info approach is something we would want to ‘bless’ just yet. You may need to align your safe point machine code analysis with [GCStrategy.cpp]LowerIntrinsics::CouldBecomeSafePoint. Note that this predicate operates on IR instructions instead of machine code. ― Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111101/6676b4fb/attachment.html>
Nicolas Geoffray
2011-Nov-01 09:53 UTC
[LLVMdev] Adding a custom GC safe point creation phase
2011/11/1 Gordon Henriksen <gordonhenriksen at mac.com>> On Nov 1, 2011, at 4:47 AM, Nicolas Geoffray <nicolas.geoffray at gmail.com> > wrote: > > 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. > > > I have my doubts about the robustness of this strategy, but if it's > working well enough for your needs, then great. >I have my doubts too. I would really like to see the metadata approach take over. Nicolas> > Your patch seems appropriately factored. The alternative would seem to be > calling a virtualized predicate on each machine instruction, as I don't > think your debug info approach is something we would want to ‘bless’ just > yet. > > You may need to align your safe point machine code analysis with > [GCStrategy.cpp]LowerIntrinsics::CouldBecomeSafePoint. Note that this > predicate operates on IR instructions instead of machine code. > > — Gordon >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111101/88b55e0b/attachment.html>
Maybe Matching Threads
- [LLVMdev] Adding a custom GC safe point creation phase
- [LLVMdev] Adding a custom GC safe point creation phase
- [LLVMdev] Adding a custom GC safe point creation phase
- [LLVMdev] GC plugin: Not add (postcall) safe point after tail-call
- [LLVMdev] Pointer vs Integer classification (was Re: make DataLayout a mandatory part of Module)