search for: gcstrategy

Hi Chris, Gordon, 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 ini...

...of 0. > > Ofcourse, i could do it in the frontend (storing -5 to all GC roots), > but i was wondering if there is another way e.g. by modifying the GC > plugin and implementing custom lowering for the gcroot intrinsic. Hello Yiannis, Yes, what you describe should be possible. In your GCStrategy subclass constructor, make the following change: class MyGCStrategy : public GCStrategy { MyGCStrategy() { - InitRoots = true; + CustomRoots = true; } + + bool performCustomLowering(Function &F) { + // You can use LowerIntrinsics::InsertRootInitializers as a template. + }...

Hello all, I set: InitRoots = true; in my gc plugin as i want the roots to be initialized to the "null" value. Is there a way to define which value should be the initial one? For example, i would like to initialize my roots to -5 (tagged, null value for the GC in my runtime system) instead of 0. Ofcourse, i could do it in the frontend (storing -5 to all GC roots), but i was wondering

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

...context is at least six months from now, but likely less than 18 months. Hopefully, that's vague enough. :) HELP - If anyone knows which Ocaml implementation and which Erlang implementation triggered the in tree GC strategies, please let me know! Near Term Changes: - Migrate ownership of GCStrategy objects from GCModuleInfo to LLVMContext. In theory, this looses the ability for two different Modules to have the same collector with different state, but I know of no use case for this. - Modify the primary Function::getGC/setGC interface to return a reference the GCStrategy object, not a st...

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

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

...pace. (minor) >>>>>> - Unless I am misreading your proposal, your proposed StackMap intrinsic duplicates existing functionality already in llvm. In particular, much of the StackMap construction seems similar to the Safepoint mechanism used by the in-tree GC support. (See CodeGen/GCStrategy.cpp and CodeGen/GCMetadata.cpp). Have you examined these mechanisms to see if you can share implementations? >>>>>> - To my knowledge, there is nothing that prevents an LLVM optimization pass from manufacturing new pointers which point inside an existing data structure. (e.g. an...

...generator (or possibly some lowering pass) to insure that this value lives on the stack during sync points, and is reloaded after a sync point if it is still needed. During a sync point, these values would be treated exactly the way llvm.gcroot works today - that is, they live on the stack, and the GCStrategy gets passed a list of stack offsets and metadata pointers. The main difference is that only the values that are actually 'live' during the sync point are lowered from SSA values to allocas. This approach offers a bunch of advantages that I can think of: - LLVM knows much more about the...

...ly some > lowering pass) to insure that this value lives on the stack during sync > points, and is reloaded after a sync point if it is still needed. During a > sync point, these values would be treated exactly the way llvm.gcroot works > today - that is, they live on the stack, and the GCStrategy gets passed a > list of stack offsets and metadata pointers. The main difference is that > only the values that are actually 'live' during the sync point are lowered > from SSA values to allocas. > > This approach offers a bunch of advantages that I can think of: > >...

Hi, I noticed that in line 288-289 of lib/CodeGen/GCStrategy.cpp there is a loop: > for (Function::iterator BB = F.begin(), E = F.end(); BB != E; ++BB) { > for (BasicBlock::iterator II = BB->begin(), E = BB->end(); > II != E;) { E is used both for F.end() and for BB->end(). Is this int...

...namespace. (minor) > - Unless I am misreading your proposal, your proposed StackMap intrinsic > duplicates existing functionality already in llvm. In particular, much of > the StackMap construction seems similar to the Safepoint mechanism used by > the in-tree GC support. (See CodeGen/GCStrategy.cpp and > CodeGen/GCMetadata.cpp). Have you examined these mechanisms to see if you > can share implementations? > - To my knowledge, there is nothing that prevents an LLVM optimization pass > from manufacturing new pointers which point inside an existing data > structure. (e.g. an...

...posed StackMap >>>>> intrinsic duplicates existing functionality already in llvm. In >>>>> particular, much of the StackMap construction seems similar to the >>>>> Safepoint mechanism used by the in-tree GC support. (See >>>>> CodeGen/GCStrategy.cpp and CodeGen/GCMetadata.cpp). Have you >>>>> examined these mechanisms to see if you can share implementations? >>>>> - To my knowledge, there is nothing that prevents an LLVM >>>>> optimization pass from manufacturing new pointers which point &gt...

I have a problem where my LLVM-generated code works on Linux but not on OS X, and the problem involves non_lazy_ptr. I have an external symbol named "@gc_safepoint_map", which is generated by the linker's GCStrategy plugin. Since it is not generated until link time, I declared it as an external symbol so that the modules that use it can compile without error. Here's what the generated IR looks like: @gc_safepoint_map = external global [0 x i32] The runtime startup code gets the safepoint map and calls...

...s to get a better understanding. Is it possible to output the llvm instructions created from the gcroot intrinsics etc after the transformation? At what compiler stage is the transformation performed? I tried to find out what it does with the llvm instructions from looking at the source code of the GCStrategy class, but I like to see an example for my own code to see what is really happening. The llvm specific cpp code is hard to understand because im not really a llvm framework developer. Another question, the GC tutorial refers to "/runtime/GC/SemiSpace/semispace.cpp" (a simple gc on top of...

...ing between > them, its hard to see how this could be part of LLVM proper. So LLVM should not be aware of "stop the world" stuff. It's really a matter of your collector. What LLVM should be aware is the position of safe points in the code. That's the case with Gordon's GCStrategy class. However, to implement "stop the world", runtimes should be able to add runtime-specific code at these safe points. If you could, then adding a cooperative, stop-the-world GC would be straightforward. Just poll a variable during the safe-point. When a collection is required, the...

Hi Martin, Philip covered all of it very well, I'll just add one minor comment: > More generally, can I back up and ask an important question? Do you have to > support deoptimization (i.e. osr side exits) in any form? If you do, you'll > probably want to avoid the PlaceSafepoints utility pass. If you need to PlaceSafepoints is inadequate only if you have asynchronous

...>> >> >>> The way that I handle non-pointer types is to generate an array of field >>> offsets (containing the offset of each pointer field within the struct) as >>> the metadata argument to llvm.gcroot. This meta argument is then processed >>> in my GCStrategy, where I add the stack root offset to the offsets in the >>> field offset array, which yields the stack offsets of the actual pointers in >>> the call frame. >>> >>> >> >> Did you think of the alternative of calling llvm.gcroot on pointers in >>...

Sure. I think we can change the GC lowering pass to recognize all llvm.gcroot (not only the ones in the first block), and move them to the first block so that they are initialized by the pass later on. On Sat, Oct 2, 2010 at 10:58 PM, Talin <viridia at gmail.com> wrote: > On Sat, Oct 2, 2010 at 12:59 PM, nicolas geoffray < > nicolas.geoffray at gmail.com> wrote: > >>

...; fields which need to be traced. > > Yes. > The way that I handle non-pointer types is to generate an array of field > offsets (containing the offset of each pointer field within the struct) as > the metadata argument to llvm.gcroot. This meta argument is then processed > in my GCStrategy, where I add the stack root offset to the offsets in the > field offset array, which yields the stack offsets of the actual pointers in > the call frame. > > Did you think of the alternative of calling llvm.gcroot on pointers in this struct? This requires to change the verifier to suppo...