similar to: [LLVMdev] reload of pointers after GC

Hi Scott, On Sep 22, 2008, at 20:59, Scott Graham wrote: > I'm using a GC that's pretty similar to the OCaml one. It records > stack locations using llvm.gcroot, and dumps out a frametable > describing the live stack offsets so that the GC runtime can walk > them as required. I'm on 2.3, not svn head. > > I'm having some trouble with pointers being cached

On Mon, Apr 21, 2008 at 8:13 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > > Hi Terence, > > > I think you're getting hung up on the details of the shadow stack collector. > The shadow stack is a GC that is possible within this framework, but of > course could be implemented without any special support. Its presence is > more misleading than anything

On Sun, Apr 27, 2008 at 9:34 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > As for the compiler plugin interface, I suggest you ignore it > initially and use the provided shadow-stack option for the time being. > The shadow stack generates significantly suboptimal code, but will let > you avoid writing some platform-specific code. Instead, simply copy > the

On 2008-04-27, at 21:29, Lane Schwartz wrote: > Hi guys, Hi Lane! This is a lot of questions. I'm not going to answer each individually, but will instead give general guidance to help you avoid the pain points… > I somehow need to inform the garbage collection runtime (my > copycollector.c) about my variables - specifically about gc roots. > So, after I get new memory

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

I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. I wrote up a bunch of my findings on the implementation of my GC here: https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme Frankly I

Hi Paul, On 2009-12-04, at 09:34, Paul Melis wrote: > I hope you don't mind me sending this mail directly to you (instead of to llvm-dev), but you seem to be the expert on LLVM's GC support :) If you'd rather have me send to llvm-dev, please say so. You'll reach a wider audience with the list, though I haven't been able to keep up with it lately. > I'm trying to

Hi, Regarding llvm.gcroot, do I have to allocate stack-space for all pointers in a function? Right now I mostly use SSA-variables, and let llvm's register allocation allocate stack-space when needed. Also, what happens when I run the mem2reg pass, does it handle llvm.gcroot's that are moved from stack to registers? I'm thinking along the lines, that should one not use llvm.gcroot on

Hi Terence, I think you're getting hung up on the details of the shadow stack collector. The shadow stack is a GC that is possible within this framework, but of course could be implemented without any special support. Its presence is more misleading than anything else. Taking a step back, the concepts are: llvm.gcroot instructs the code generator --> My GC needs to be able to

On Apr 20, 2008, at 6:52 PM, Gordon Henriksen wrote: > On 2008-04-20, at 21:05, Terence Parr wrote: > >> On Apr 20, 2008, at 5:36 PM, Gordon Henriksen wrote: >> >>> Since the semispace heap doesn't actually work (it's an example, >>> at best), I suggest you simply copy the stack visitor into your >>> project; it's only a dozen lines of

> On Oct 26, 2013, at 12:37 AM, Michael Lewis <don.apoch at gmail.com> wrote: > > I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. You can implement a copying GC (what the kids these days

Howdy do LLVM folks! I've exhausted what I can do on my own to make a GC example bind (usual googling, reading, playing, looking at source). I can't find the shadow collector lib or perhaps the -l options needed to link my sample (not even to point where I'm figuring out GC actually as I can't link). Not sure this IR is correct but here is what I've been playing

On 02/14/2014 05:55 PM, Philip Reames wrote: > Splitting out a conversation which started in "make DataLayout a > mandatory part of Module" since the topic has decidedly changed. This > also relates to the email "RFC: GEP as canonical form for pointer > addressing" I just sent. > > On 02/10/2014 05:25 PM, Nick Lewycky wrote: >> ... >> >>

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

Talin wrote: > Jon wrote: > > Talin wrote: > > > Garbage collection is still way too difficult. > > > > This is completely untrue. > > I'm afraid I'm going to have to disagree... I failed to get my point across. You're still talking about the difficulty of using LLVM's GC support. I was talking about circumventing it. The shadow stack HLVM uses

On Aug 19, 2007, at 20:43, Chris Lattner wrote: > On Aug 14, 2007, at 4:35 AM, Gordon Henriksen wrote: > >> On Aug 14, 2007, at 06:24, Gordon Henriksen wrote: >> >>> The two major problems I had really boil down to identifying GC >>> points in machine code and statically identifying live roots at >>> those GC points, both problems common to many

On 02/24/2014 12:45 AM, Andrew Trick wrote: > > On Feb 21, 2014, at 10:37 AM, Philip Reames <listmail at philipreames.com > <mailto:listmail at philipreames.com>> wrote: > >> >> On 02/14/2014 05:55 PM, Philip Reames wrote: >>> Splitting out a conversation which started in "make DataLayout a >>> mandatory part of Module" since the

On Wed, Sep 22, 2010 at 5:58 AM, Kenneth Uildriks <kennethuil at gmail.com>wrote: > On Tue, Sep 21, 2010 at 8:20 PM, Talin <viridia at gmail.com> wrote: > > On Mon, Sep 20, 2010 at 3:16 PM, Talin <viridia at gmail.com> wrote: > >> > >> So I've managed to get my stack crawler working and passing its unit > tests > >> - this is the one

Thanks for reviving this. I completely forgot the details but I resolved this problem. Looking though the code, seems I forked RewriteStatepointsForGC pass, and change it to adding 'gc-livevars' bundle to the call/invoke inst after finding the livevars, instead of changing it to StatepointCall intrinsic. On Wed, Nov 14, 2018 at 11:48 AM Philip Reames <listmail at philipreames.com>

On Mon, 19 Jul 2004, Tobias Nurmiranta wrote: > Regarding llvm.gcroot, do I have to allocate stack-space for all > pointers in a function? Right now I mostly use SSA-variables, and let > llvm's register allocation allocate stack-space when needed. Yes. This reflects the fact that the GC can move objects (to compact the heap) at unpredictable times. > Also, what happens when I