similar to: [LLVMdev] Extending GC infrastructure for roots in SSA values

First of all, thanks for looking into this! As you've no doubt discovered, I'm one of the people who has talked a lot about this issue in the past, and have been frustrated with the lack of progress in this area. I completely agree with your point about wanting to be able to attach GC metadata to a type (rather than attaching it to a value, as is done now). In the past, there have been

On Sun, Dec 30, 2012 at 2:17 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 30 Dec 2012, at 01:54, Talin wrote: > > > I completely agree with your point about wanting to be able to attach GC > metadata to a type (rather than attaching it to a value, as is done now). > In the past, there have been two objections to this approach: first, the > overhead

On 30 Dec 2012, at 01:54, Talin wrote: > I completely agree with your point about wanting to be able to attach GC metadata to a type (rather than attaching it to a value, as is done now). In the past, there have been two objections to this approach: first, the overhead that would be added to the Pointer type - the vast majority of LLVM users don't want to have to pay an extra 4-8 bytes per

On Sat, Dec 29, 2012 at 5:54 PM, Talin <viridia at gmail.com> wrote: > First of all, thanks for looking into this! As you've no doubt discovered, > I'm one of the people who has talked a lot about this issue in the past, and > have been frustrated with the lack of progress in this area. Yeah, I spent some time digging through the archives. Frankly, I'm surprised

On Thu, Feb 17, 2011 at 1:07 PM, Talin <viridia at gmail.com> wrote: > On Wed, Feb 16, 2011 at 4:51 PM, Talin <viridia at gmail.com> wrote: > >> 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

A couple people have asked about this, so I wanted to describe my proposals for improving LLVM's garbage collection intrinsics. Currently the llvm.gcroot intrinsic associates a set of GC metadata with a value, specifically a value produced by an alloca instruction. In the proposed scheme, GC metadata would instead be associated with a *type*. The most general approach would be to introduce a

Hi Talin, On Fri, Feb 18, 2011 at 1:36 AM, Talin <viridia at gmail.com> wrote: > > Thinking about it even more, here's a short summary of what I would > propose: > > - *llvm.gc.value*(value, metadata) - marks an SSA value as a garbage > collection root. This remains in effect for the lifetime of the SSA value. > - *llvm.gc.declare*(alloca, metadata) - marks

(This is a summary of the big long thread on llvm.gcroot, for those who didn't have time to read it.) I'm proposing the replacement of llvm.gcroot() with three new intrinsics: - *llvm.gc.declare*(alloca, meta). This intrinsic marks an alloca as a garbage collection root. It can occur anywhere within a function, and lasts either until the end of the function, or a until matching

On Sep 2, 2007 5:31 AM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > Hi Talin, > > On Sep 2, 2007, at 04:54, Talin wrote: > > > I've been looking through the documentation (http://llvm.org/docs/ > > GarbageCollection.html) on how to implement a garbage collector for > > LLVM and there's a couple of things that I don't quite understand. >

Hello llvm-dev! My colleages and I are currently evaluating llvm's suitability as a JIT compiler interfacing with a precise, relocating garbage collector. While we couldn't find code or writeups that deal with the issues specific to this design goal, it is entirely possible that we may have missed something; we would appreciate references to relevant code or writeups that people on this

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

On Fri, Feb 18, 2011 at 1:05 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > Hi Talin, > > On Fri, Feb 18, 2011 at 1:36 AM, Talin <viridia at gmail.com> wrote: >> >> Thinking about it even more, here's a short summary of what I would >> propose: >> >> - *llvm.gc.value*(value, metadata) - marks an SSA value as a garbage

Talin, how about having the front-end generate an llvm.safe.point () intrinsic call at the desired safe points, and having the addresses of the GC roots (at that point, can vary from call to call) be the parameters (with noescape attribute) to the intrinsic, IIUC currently the GC roots are tagged, and all analysis and transform optimizations have to special case these tagged

So I've been using LLVM for about 4 years now, and I've posted a lot on this list about specific issues. What I would like to do is step back for a moment and give my "big picture" assessment of LLVM overall, particularly with respect to developing a "managed" language like Java / C# or my own language, Tart. Obviously, I feel that LLVM is the best choice out there,

On Wed, Jul 6, 2011 at 3:51 PM, Kenneth Uildriks <kennethuil at gmail.com>wrote: > On Wed, Jul 6, 2011 at 5:24 PM, Talin <viridia at gmail.com> wrote: > > > One approach would be to extend the current scheme to work with SSA > values, > > possibly using a new intrinsic. This is somewhat problematic because you > > can't really have a 'do-nothing'

Just a thought, but it would it make sense for garbage collection to be some sort of minimal debug information for potentially optimized code. Store just enough debug information to reconstruct call stacks and know where gc-roots are. Perhaps an approach like this could minimize the work required as it is shared between gc-support and debug information support. >From what I understand, DWARF

Hi all, I've been looking through the documentation (http://llvm.org/docs/GarbageCollection.html) on how to implement a garbage collector for LLVM and there's a couple of things that I don't quite understand. Specifically, it says that when a stack variable goes out of scope, you're supposed to assign a null value to it to indicate that the value is no longer live. What I

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

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 code or so. > > > Ok, copying; can't find ShadowStackEntry though.

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 I've been working on as an alternative to shadow-stack: it >> uses only static constant data structures (no