search for: gcroots

...D. >> >> Ugh. If all roots have to be singleton pointers, not embedded >> within a larger structure, then I'm not sure that what I want to >> do is even possible. > In principle you could probably mark the alloca's of your value > structs as gcroots. Then during collection you would have to make > sure you recognize the value types so you don't > move/deallocate/... them during a collection. That would still > give you the option to trace all live objects by simply traversing > the fields of a value struct. You...

...allocate a class instance on the stack in D. > > Ugh. If all roots have to be singleton pointers, not embedded within a > larger structure, then I'm not sure that what I want to do is even > possible. In principle you could probably mark the alloca's of your value structs as gcroots. Then during collection you would have to make sure you recognize the value types so you don't move/deallocate/... them during a collection. That would still give you the option to trace all live objects by simply traversing the fields of a value struct. You would only have to do this for value...

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

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

...part of Module" since the topic has decidedly changed. This > also relates to the email "RFC: GEP as canonical form for pointer > addressing" I just sent. > > On 02/10/2014 05:25 PM, Nick Lewycky wrote: >> ... >> >> We're supposed to have the llvm.gcroots intrinsic for this purpose, >> but you note that it prevents gc roots from being in registers (they >> must be in memory somewhere, usually on the stack), and that fixing >> it is more work than is reasonable. > This is slightly off, but probably close to what I actually sai...

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

...ed. >>> This also relates to the email "RFC: GEP as canonical form for >>> pointer addressing" I just sent. >>> >>> On 02/10/2014 05:25 PM, Nick Lewycky wrote: >>>> ... >>>> >>>> We're supposed to have the llvm.gcroots intrinsic for this purpose, >>>> but you note that it prevents gc roots from being in registers >>>> (they must be in memory somewhere, usually on the stack), and that >>>> fixing it is more work than is reasonable. >>> This is slightly off, but proba...

...instance on the stack in D. >> >> Ugh. If all roots have to be singleton pointers, not embedded within a > larger structure, then I'm not sure that what I want to do is even possible. > > In principle you could probably mark the alloca's of your value structs as > gcroots. Then during collection you would have to make sure you recognize > the value types so you don't move/deallocate/... them during a collection. > That would still give you the option to trace all live objects by simply > traversing the fields of a value struct. You would only have to do...

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 that means it > must be an alloca (which is always a pointer by definition) or an alloca > *of* a pointer. I'm pretty sure it should be "alloca of a pointer", as the first argument of llvm.gcroot has type i8**.

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

I’ve been tinkering around with some llvm assembly trying out some of the GC related features. When I add a call to @llvm.gcroot, it is consistently acting like it doesn’t know what that function is. I’m just getting started so it is probably something small and simple but some googling didn’t yield much in the way of an answer. Any help is appreciated. Thanks, Todd

I'm allocating { i8*, i32 } on the stack, and would like to add this as a GC root, but I'm having trouble figuring this out. This works as expected: declare void @llvm.gcroot(i8** %ptrloc, i8* %metadata) define i8* @bar(i8* %x) gc "shadow-stack" { entry: %objptr = alloca i8* call void @llvm.gcroot(i8** %objptr, i8* null) store i8* %x, i8** %objptr %v = load i8*, i8**

Solved by using alloca i8*, i32 2 which the system seems happy enough with, and bitcasting to the actual type for rest of the code after llvm.gcroot. Not entirely sure if this is a terrible workaround or exactly the way gcroot is supposed to be used... On Wed, Nov 1, 2017 at 11:59 AM, Nikodemus Siivola < nikodemus at random-state.net> wrote: > I'm allocating { i8*, i32 } on the

...l "RFC: GEP as canonical form for >>>>> pointer addressing" I just sent. >>>>> >>>>> On 02/10/2014 05:25 PM, Nick Lewycky wrote: >>>>>> ... >>>>>> >>>>>> We're supposed to have the llvm.gcroots intrinsic for this >>>>>> purpose, but you note that it prevents gc roots from being in >>>>>> registers (they must be in memory somewhere, usually on the >>>>>> stack), and that fixing it is more work than is reasonable. >>>>>...

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 a pointer alloca. I'm not sure whether that means > it > > must be an alloca (which is always a pointer by definition) or an alloca > > *of* a

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

So I understand now that calls to llvm.gcroot have to be in the first block. (Might be a good idea to mention this in the GC docs). For each local variable that is created, there are 5 possible steps. 1. Allocate the storage for the variable using alloca(). 2. Declare the variable as a root via llvm.gcroot. 3. Initialize the variable to zero. 4. Declare the DWARF debugging info for

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 wouldn't allow it. I've used this patch to build an

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

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