similar to: [LLVMdev] llvm.gcroot suggestion

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

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 - >> >> >>> For example, suppose I have a type "String or (float, float, float)" - >>> that is, a union of a string and a

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

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

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

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

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

Hi Talin, Let me ask a question before we go too much further. Currently the argument > to llvm.gcroot must be an alloca instruction. You cannot GEP an internal > field within the alloca and pass it to the gcroot intrinsic. So the entire > alloca is considered a root, even if it has non-pointer fields. My question > is, in this new address-space proposal, are we talking about changing

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

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

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 Tue, Mar 8, 2011 at 12:11 PM, Joshua Warner <joshuawarner32 at gmail.com>wrote: > > Hi Talin, > > Let me ask a question before we go too much further. Currently the argument >> to llvm.gcroot must be an alloca instruction. You cannot GEP an internal >> field within the alloca and pass it to the gcroot intrinsic. So the entire >> alloca is considered a root,

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