similar to: [LLVMdev] Template and GC root

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

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

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

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

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

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

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 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 Mon, 19 Jul 2004, Tobias Nurmiranta wrote: > > Not currently. In the future this will definitely be improved. In > > particular, when the code generators are enhanced to provide more accurate > > mapping information for GC pointers (e.g. which registers contain > > pointers), we can do this. This is in the long term plans, but I suspect > > that performance will

On Mon, 19 Jul 2004, Chris Lattner wrote: > 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

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

I'm trying to add gcoot functionality to my code and I'm confused by why gcroot is assuming to be an i8** I'm using i32 as object and array pointers and if I make them i8 things seem to work. I'm generating IR much like http://llvm.org/docs/GarbageCollection.html#llvm-ir-features void @llvm.gcroot(i8** %ptrloc, i8* %metadata) -------------- next part -------------- An HTML

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

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

Hi Team, I'm working on a new pure functional language and I'm trying to add GC support for that. Because all vars are immutable, the IR that my frontend generates are all register based, i.e. no alloca, and no readmem, writemem unless accessing/constructing structs. If I use the traditional GC with gcroot intrinsic, it will need to emit more code for liveness tracking, storing the IR

On Apr 28, 2008, at 14:28, Lane Schwartz wrote: > 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

Hi 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 in registers across function calls (at least x86 backend, haven't tried others yet).

On Fri, Oct 25, 2013 at 8:35 PM, Philip Reames <listmail at philipreames.com>wrote: > On 10/25/13 1:10 PM, Ben Karel wrote: > > > > > On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com>wrote: > >> Hi Rafael, Andrew, >> >> Thank you for the prompt reply. >> >> One approach we've been considering involves