similar to: [LLVMdev] Proposal for improving llvm.gcroot (summarized)

On 30 March 2011 19:08, Talin <viridia at gmail.com> wrote: > 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 call to > llvm.gc.undeclare(). > llvm.gc.undeclare(alloca). This intrinsic unmarks and alloca, so that it is

On Fri, Apr 1, 2011 at 1:58 AM, Jay Foad <jay.foad at gmail.com> wrote: > On 30 March 2011 19:08, Talin <viridia at gmail.com> wrote: > > 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 call to

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

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

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

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

>> if (cond) { >>  llvm.gc.declare(foo, bar); >> } >> ... >> // foo may or may not be a root here >> ... >> if (cond) { // same condition as above >>  llvm.gc.undeclare(foo); >> } >> > You would need to do the same as what is done today: Move the declare > outside of the condition, and initialize the variable to a null state, such

On Mon, Feb 21, 2011 at 1:50 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > 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,

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

On Fri, Apr 1, 2011 at 2:17 PM, Jay Foad <jay.foad at gmail.com> wrote: > This is very similar to the problem of representing lexical scopes in > debug info. The llvm.dbg.region.* intrinsics were the wrong way of > doing it, because of the problems I mentioned above. Now we use > metadata attached  to each instruction to say what scope it is in, > which is much better, because

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

On 04/29/10 21:27, Talin wrote: > On Wed, Apr 28, 2010 at 12:16 PM, Paul Melis > <llvm at assumetheposition.nl <mailto:llvm at assumetheposition.nl>> wrote: > > 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: >> >>

On Wed, Apr 28, 2010 at 12:16 PM, Paul Melis <llvm at assumetheposition.nl>wrote: > On 04/27/10 00:20, Talin wrote: > > On Mon, Apr 26, 2010 at 12:44 AM, Paul Melis <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

On Mon, Mar 7, 2011 at 2:05 PM, Joshua Warner <joshuawarner32 at gmail.com>wrote: > > > On Mon, Mar 7, 2011 at 12:48 PM, Talin <viridia at gmail.com> wrote: > >> On Mon, Mar 7, 2011 at 10:58 AM, Joshua Warner <joshuawarner32 at gmail.com>wrote: >> >>> Hi Talin, >>> >>> Sorry to interject - >>> >>>

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

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

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

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