search for: gcfunctioninfo

...their // allocas to null before the first use. This is @@ -135,6 +145,7 @@ /// which the LLVM IR can be modified. virtual bool initializeCustomLowering(Module &F); virtual bool performCustomLowering(Function &F); + virtual bool findCustomSafePoints(GCFunctionInfo& FI, MachineFunction& MF); }; } Index: lib/CodeGen/GCStrategy.cpp =================================================================== --- lib/CodeGen/GCStrategy.cpp (revision 141409) +++ lib/CodeGen/GCStrategy.cpp (working copy) @@ -97,6 +97,7 @@ CustomReadBarriers(false), Custom...

Hi Chris, Chris Lattner wrote: > You haven't missed anything, there isn't currently a way to do this. > Good to know. Anything against making the codegen pass manager accessible to users? Something like ExecutionEngine::getCommonCodegenPassManager() ? Thanks, Nicolas

On Sep 15, 2009, at 12:00 AM, Nicolas Geoffray wrote: > Hi Chris, > > Chris Lattner wrote: >> You haven't missed anything, there isn't currently a way to do this. >> > > Good to know. Anything against making the codegen pass manager > accessible to users? Something like > ExecutionEngine::getCommonCodegenPassManager() ? I don't have a problem with

Hi all, This patch adds a GCModuleInfo field to the MachineFunction class, to facilitate the retrieval of a potential GCFunctionInfo attached to the function. The motivation for the change is to get access in a proper way to the GC info when generating the function with the JIT. Currently, retrieving this information requires a lot of hacks (eg VMKit's code lib/J3/Compiler/JavaJITCompiler.cpp). Because a MachineInfo object...

...GCString and getGCString. - Extend the GCStrategy class to include a notion of which compilation strategy is being used. The two choices right now will be Legacy and Statepoint. (Longer term, this will likely become a more fine grained choice.) - Separate GCStategy and related pieces from the GCFunctionInfo/GCModuleInfo/GCMetadataPrinter lowering code. At first, this will simply mean clarifying documentation and rearranging code a bit. - Document/clarify the callbacks used to customize the lowering. Decide which of these make sense to preserve and document. (Lest anyone get the wrong idea, the abo...

...s 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...

...e are coming for the safepoint_17 and then find the locations of the objects? If a patchpoint can work like this, it's probably a good building block for the gc. Currently, we have to declare the root objects with the root intrinsic, then add the appropriate safepoints (it's just a call to GCFunctionInfo.addSafePoint). As root objects are marked as root, modifying GCFunctionInfo.addSafepoint to generate a patchpoint with all the gc roots as argument (instead of using the current infrastructure) should not be difficult. And it probably means that the current gc infrastructure could use patchpoint as...

...ly 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 !=...

...Collector was confusing to implementors. Several thought that this compile-time class was the place to implement their runtime GC heap. Of course, it doesn't even exist at runtime. Specifically, the renames are: Collector -> GCStrategy CollectorMetadata -> GCFunctionInfo CollectorModuleMetadata -> GCModuleInfo CollectorRegistry -> GCRegistry Function::getCollector -> getGC [setGC, hasGC, clearGC] Several accessors and nested types have also been renamed to be consistent. These changes should be obvious. Please let me know if you have a...

Hi all, I have implemented a GC plugin and i want to exclude Tail-call instructions from being considered as Safe Points. For that reason I have overwritten the "findCustomSafePoints" function with something like that: bool ErlangGC::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()...

...e-world safepoints). Also, the set of roots (which are recorded in the stack map) must be provided separately using the gcroot intrinsic. > > In code: > - GCPoint in llvm/include/llvm/CodeGen/GCMetadata.h describes a request for a location with a stack map. The SafePoints structure in GCFunctionInfo contains a list of these locations. > - The Ocaml GC is probably the best example of usage. See llvm/lib/CodeGen/AsmPrinter/OcamlGCPrinter.cpp > > Note: The summary of existing LLVM details above is based on reading the code. I haven't actually implemented anything which used this m...

...return address of a > call instruction, which is precisely what's required to walk the stack. This > is NOT the location where you want to add a call to your runtime. > I think you're saying that we need two kinds of safe points: points at which to insert code, and points that the GCFunctionInfo::iterator traverses. The code-inserting safe points could insert traversed safe points. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090623/57aa3d10/attachment.html>

...s and stop-the-world safepoints). Also, the set of roots (which are recorded in the stack map) must be provided separately using the gcroot intrinsic. In code: - GCPoint in llvm/include/llvm/CodeGen/GCMetadata.h describes a request for a location with a stack map. The SafePoints structure in GCFunctionInfo contains a list of these locations. - The Ocaml GC is probably the best example of usage. See llvm/lib/CodeGen/AsmPrinter/OcamlGCPrinter.cpp Note: The summary of existing LLVM details above is based on reading the code. I haven't actually implemented anything which used this mechanism yet...

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

Hi Jeffrey, On 2009-06-22, at 01:49, Jeffrey Yasskin wrote: > I need to add thread-switching support to Unladen Swallow's JIT, and > LLVM's safe point support looks like a good way to get code into all > the right places. However, http://llvm.org/docs/GarbageCollection.html#collector-algos > points out that there's no way to emit code at safe points yet, and >

Hi all, I need to add thread-switching support to Unladen Swallow's JIT, and LLVM's safe point support looks like a good way to get code into all the right places. However, http://llvm.org/docs/GarbageCollection.html#collector-algos points out that there's no way to emit code at safe points yet, and there are no loop safe points at all. So I'll be trying to implement them. Is

On Oct 22, 2013, at 3:08 PM, Filip Pizlo <fpizlo at apple.com> wrote: > On Oct 22, 2013, at 1:48 PM, Philip R <listmail at philipreames.com> wrote: > >> On 10/22/13 10:34 AM, Filip Pizlo wrote: >>> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: >>> >>>> On 10/17/13 10:39 PM, Andrew Trick wrote:

On Oct 22, 2013, at 1:48 PM, Philip R <listmail at philipreames.com> wrote: > On 10/22/13 10:34 AM, Filip Pizlo wrote: >> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: >> >>> On 10/17/13 10:39 PM, Andrew Trick wrote: >>>> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The >>>> first client