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**. However, http://llvm.org/docs/GarbageCollection.html#gcroot, isn't completely clear on this: "The first argument must be a value referring to an alloca instruction or a bitcast of an alloca." This last sentence seems to rule out passing GEPs on alloca's to llvm.gcroot.> What I am trying to figure out is how to declare roots contained in value > types. Suppose for example I have a small struct which contains several > garbage-collectable references. This struct is a local variable, so it's > contained in a block of memory which has been allocated via alloca. Now, I > don't want to add the struct itself as a root, since it isn't allocated on > the heap. But I want to declare the fields within the struct - which are > GEPs from the alloca pointer - as roots, since they are references to > objects on the heap.As reasonable as the above sounds, I don't think you can mark roots contained in structs. But if I'm wrong I'd love to know ;-) Perhaps you can ask the LDC devs how/if they handle this case, as it seems you can allocate a class instance on the stack in D. Regards, Paul
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 pointer. > > I'm pretty sure it should be "alloca of a pointer", as the first argument > of llvm.gcroot has type i8**. > > However, http://llvm.org/docs/GarbageCollection.html#gcroot, isn't > completely clear on this: > > "The first argument must be a value referring to an alloca instruction or > a bitcast of an alloca." > > This last sentence seems to rule out passing GEPs on alloca's to > llvm.gcroot. > > > What I am trying to figure out is how to declare roots contained in value > > types. Suppose for example I have a small struct which contains several > > garbage-collectable references. This struct is a local variable, so it's > > contained in a block of memory which has been allocated via alloca. Now, > I > > don't want to add the struct itself as a root, since it isn't allocated > on > > the heap. But I want to declare the fields within the struct - which are > > GEPs from the alloca pointer - as roots, since they are references to > > objects on the heap. > > As reasonable as the above sounds, I don't think you can mark roots > contained in structs. But if I'm wrong I'd love to know ;-) Perhaps you > can ask the LDC devs how/if they handle this case, as it seems you can > allocate a class instance on the stack in D. > > Ugh. If all roots have to be singleton pointers, not embedded within alarger structure, then I'm not sure that what I want to do is even possible.> Regards, > Paul > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100426/48c0756e/attachment.html>
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 > 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**. > > However, http://llvm.org/docs/GarbageCollection.html#gcroot, isn't > completely clear on this: > > "The first argument must be a value referring to an alloca > instruction or > a bitcast of an alloca." > > This last sentence seems to rule out passing GEPs on alloca's to > llvm.gcroot. > > > What I am trying to figure out is how to declare roots contained > in value > > types. Suppose for example I have a small struct which contains > several > > garbage-collectable references. This struct is a local variable, > so it's > > contained in a block of memory which has been allocated via > alloca. Now, I > > don't want to add the struct itself as a root, since it isn't > allocated on > > the heap. But I want to declare the fields within the struct - > which are > > GEPs from the alloca pointer - as roots, since they are > references to > > objects on the heap. > > As reasonable as the above sounds, I don't think you can mark roots > contained in structs. But if I'm wrong I'd love to know ;-) > Perhaps you > can ask the LDC devs how/if they handle this case, as it seems you can > 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 structs (indirectly) containing references. Does that make sense? BTW, I checked the LDC sources, they don't use LLVM's GC support, but use their own GC stuff in D, so no clues there... Regards, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100428/978d0c21/attachment.html>