similar to: [LLVMdev] Initializing GC roots

On Oct 6, 2011, at 17:19, Yiannis Tsiouris wrote: > 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. >

Hi I'm getting an assert in LowerIntrinsics::InsertRootInitializers because I'm gcroot'ing an alloca to a non-pointer. I was hoping to modify InsertRootInitializers to memset the structure in the case that it's not a pointer, but I'm not sure how to. Can anyone suggest what should go at "todo; something here"? ... for (AllocaInst **I = Roots, **E = Roots +

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 initialization. It works pretty well, as

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

On Sat, Oct 2, 2010 at 12:59 PM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > Hi Talin, > > You are not doing something wrong, it is just that the LLVM optimizers > consider llvm.gcroot like a regular function call. The alloca is moved in > the first block most probably because the inliner anticipates another > optimization pass (the mem2reg). > OK, well,

I'm allocating { i8*, i32 } on the stack, and would like to add this as a GC root, but I'm having trouble figuring this out. This works as expected: declare void @llvm.gcroot(i8** %ptrloc, i8* %metadata) define i8* @bar(i8* %x) gc "shadow-stack" { entry: %objptr = alloca i8* call void @llvm.gcroot(i8** %objptr, i8* null) store i8* %x, i8** %objptr %v = load i8*, i8**

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

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.

On Nov 7, 2008, at 15:29, Scott Graham wrote: > I'm getting an assert in LowerIntrinsics::InsertRootInitializers > because I'm gcroot'ing an alloca to a non-pointer. > > I was hoping to modify InsertRootInitializers to memset the > structure in the case that it's not a pointer, but I'm not sure how > to. Can anyone suggest what should go at "todo;

Solved by using alloca i8*, i32 2 which the system seems happy enough with, and bitcasting to the actual type for rest of the code after llvm.gcroot. Not entirely sure if this is a terrible workaround or exactly the way gcroot is supposed to be used... On Wed, Nov 1, 2017 at 11:59 AM, Nikodemus Siivola < nikodemus at random-state.net> wrote: > I'm allocating { i8*, i32 } on the

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 intended? -Y. -- Yiannis Tsiouris Ph.D.

|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 intended? Note that it's also being

LLVM has two similar bits of infrastructure: a simplifyInstructionsInBlock function and a SimplifyInstructions pass, both intended to be lightweight “fix up this code without doing serious optimizations” functions, as far as I can tell. I don’t think either is used in a performance-sensitive place in-tree; the former is mostly called in minor places when doing CFG twiddling, and the latter seems

On Tue, May 5, 2015 at 10:20 AM, Jingyue Wu <jingyue at google.com> wrote: > Hi Daniel, > > I presume you mean, instead of assigning function arguments distinct ranks > (http://llvm.org/docs/doxygen/html/Reassociate_8cpp_source.html#l00282), we > should group function arguments in favor of existing pairings. Existing = pairings reassociate already chose before *not* existing

Now that the statepoint changes have landed, I wanted to start a discussion about what's next for GC support in LLVM. I'm going to sketch out a strawman proposal, but I'm not set on any of this. I mostly just want to draw interested parties out of the woodwork. :) Overall Direction: In the short term, my intent is to preserve the functionality of the existing code, but migrate

Hello, I have a few suggestions for the GC interface. First, initialization of roots fails if the root isn't just a pointer. Some implementations require more data than just the pointer for handling references to the interior of an aggregate. On my end it just required changing ConstantPointerNull::get() to Constant::GetNullValue() to support fat pointers. The roots that were being

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

I think I'm one of the few people actually using LLVM's support for garbage collection, and so far I've found it very difficult to generate code that uses llvm.gcroot() correctly. In the current scheme, it is the frontend's responsibility to insure that any intermediate SSA values containing references to garbage collectible objects are copied to stack variables so that the GC

I'm moving this to a different thread. I think the newly proposed intrinsic definitions and their current implementation are valuable regardless of how it gets tied into GC... On Oct 22, 2013, at 6:24 PM, Philip R <listmail at philipreames.com> wrote: > Adding Gael as someone who has previously discussed vmkit topics on the list. Since I'm assuming this is where the GC support

Adding Gael as someone who has previously discussed vmkit topics on the list. Since I'm assuming this is where the GC support came from, I wanted to draw this conversation to the attention of someone more familiar with the LLVM implementation than myself. On 10/22/13 4:18 PM, Andrew Trick wrote: > On Oct 22, 2013, at 3:08 PM, Filip Pizlo <fpizlo at apple.com > <mailto:fpizlo