similar to: [LLVMdev] Patch to allow llvm.gcroot to work with non-pointer allocas.

On Sep 22, 2010, at 8:52 AM, Talin wrote: > I'm moving this thread to llvm-dev in the hopes of reaching a wider audience. > > This patch relaxes the restriction on llvm.gcroot so that it can work with non-pointer allocas. The only changes are to Verifier.cpp - it appears from my testing that llvm.gcroot always worked fine with non-pointer allocas, except that the verifier

Thanks for the heads up Chris. Talin, how is your GC dealing with non-pointers (be it allocas or not)? What is the use-case (either in C or LLVM)? Nicolas On Fri, Sep 24, 2010 at 7:00 PM, Chris Lattner <clattner at apple.com> wrote: > On Sep 22, 2010, at 8:52 AM, Talin wrote: > > I'm moving this thread to llvm-dev in the hopes of reaching a wider > audience. > >

On Fri, Sep 24, 2010 at 10:44 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > Thanks for the heads up Chris. > > Talin, how is your GC dealing with non-pointers (be it allocas or not)? > What is the use-case (either in C or LLVM)? > Many languages support the notion of a "value type". Value types are always passed by value, unlike reference types

Hi Talin, On Sat, Sep 25, 2010 at 4:18 AM, Talin <viridia at gmail.com> wrote: > > > Many languages support the notion of a "value type". Value types are always > passed by value, unlike reference types which are always passed by > pointer. An example is the "struct" type in C#. Another example is a "tuple" > type. A value type which is a

I didn't have unions in mind - indeed you need some kind of static information in such a case. The GC infrastructure in LLVM having so little love, I think it is good if you can improve it in any ways, as well as defining new interfaces. Cheers, Nicolas On Sat, Sep 25, 2010 at 6:38 PM, Talin <viridia at gmail.com> wrote: > On Sat, Sep 25, 2010 at 1:04 AM, nicolas geoffray < >

On Sat, Sep 25, 2010 at 1:04 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > Hi Talin, > > On Sat, Sep 25, 2010 at 4:18 AM, Talin <viridia at gmail.com> wrote: >> >> >> Many languages support the notion of a "value type". Value types are >> always passed by value, unlike reference types which are always passed by >>

On Sat, Sep 25, 2010 at 10:51 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > I didn't have unions in mind - indeed you need some kind of static > information in such a case. The GC infrastructure in LLVM having so little > love, I think it is good if you can improve it in any ways, as well as > defining new interfaces. So the patch is OK then? All it does

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 still putting the final touches on my stack crawler, and I've run into a problem having to do with function inlining and local stack roots. As you know, all local roots must be initialized before you can make any call to a function which might crawl the stack. My compiler ensures that all local variables of a function are allocated, declared as root, and initialized in the first

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

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). Cheers, Nicolas On Sat, Oct 2, 2010 at 8:28 PM, Talin <viridia at gmail.com> wrote: > I'm still putting the final touches on

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 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 the current scheme, it is the frontend's responsibility to insure that > any intermediate SSA

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

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

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

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 global variables or thread-local data), which means that it's fully compatible with a multi-threaded environment. One question that has arisen, however, is what to do about function

Hi Talin, On Fri, Feb 18, 2011 at 5:50 PM, Talin <viridia at gmail.com> wrote: > > > In the current scheme, the way you tell LLVM that a root is no longer > needed is by assigning NULL to it. However, that assumes that all roots are > pointers, which is not true in my world - a root can be a struct containing > pointers inside of it. (In my current frontend, a non-pointer

Hi Talin, On Sat, Mar 5, 2011 at 6:42 PM, Talin <viridia at gmail.com> wrote: > > > So I've been thinking about your proposal, that of using a special address > space to indicate garbage collection roots instead of intrinsics. Great! > > To address this, we need a better way of telling LLVM that a given variable > is no longer a root. > Live variable

On 04/27/10 00:20, Talin wrote: > On Mon, Apr 26, 2010 at 12:44 AM, Paul Melis > <llvm at assumetheposition.nl <mailto:llvm at assumetheposition.nl>> wrote: > > Hi, > > Talin wrote: > > I'm a little confused as to the rules for the arguments to > llvm.gcroot, > > which says it must be a pointer alloca. I'm not sure whether