search for: llvm_gc_write

On Sun, 2008-04-27 at 22:34 -0400, Gordon Henriksen wrote: > On 2008-04-27, at 21:29, Lane Schwartz wrote: > > Since this is a simple copying collector, the functions llvm_gc_read > > and llvm_gc_write won't really do much: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { return > > *FieldPtr; } > > void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) > > { *FieldPtr = V; } > > You can just emit loads and stores directly if your read/write &gt...

On Mon, 27 Feb 2006, Sandro Magi wrote: > Couple of questions: Ok, it's been a long while since I've worked on the GC stuff, but I'll try to help :) > 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) > > I haven't seen an adequate explanation of these, but I'm guessing: > void *V: value being written to the field > void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr > upon entry to llvm_gc_write) > void **FieldPt...

Couple of questions: 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) I haven't seen an adequate explanation of these, but I'm guessing: void *V: value being written to the field void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr upon entry to llvm_gc_write) void **FieldPtr: address of the field be...

...locate. These function names are entirely optional. Your runtime can use any names and prototypes it likes to provide this functionality. A bump- ptr allocator might easily inline part of its allocation routine. > Since this is a simple copying collector, the functions llvm_gc_read > and llvm_gc_write won't really do much: > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { return > *FieldPtr; } > void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) > { *FieldPtr = V; } You can just emit loads and stores directly if your read/write barriers do nothing. Also, there&...

...e for a program, it should also generate a call (early in the IR code) to llvm_gc_initialize. This function uses the system calloc to allocate two big blocks of memory, then stores pointers to that memory in static variables. Since this is a simple copying collector, the functions llvm_gc_read and llvm_gc_write won't really do much: void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { return *FieldPtr; } void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) { *FieldPtr = V; } There is also a function called llvm_gc_allocate. Now, instead of using alloca or malloc, my frontend generates a call to...

On Apr 28, 2008, at 10:50, Jonathan S. Shapiro wrote: > On Sun, 2008-04-27 at 22:34 -0400, Gordon Henriksen wrote: >> On 2008-04-27, at 21:29, Lane Schwartz wrote: >>> Since this is a simple copying collector, the functions >>> llvm_gc_read and llvm_gc_write won't really do much: >>> void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { return >>> *FieldPtr; } >>> void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) >>> { *FieldPtr = V; } >> >> You can just emit loads and stores directly if yo...

On 2/27/06, Chris Lattner <sabre at nondot.org> wrote: > > 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) > > > > I haven't seen an adequate explanation of these, but I'm guessing: > > void *V: value being written to the field > > void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr > > upon entry to llvm_gc_wr...

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = getelementptr

...ore. At code generation --- > second has the same semantics as a non-volatile LLVM store, with the > additions that they also take a pointer to the start of the memory > object as an argument. At code generation 344,345c346,347 < void *llvm_gc_read(void **)<br> < void llvm_gc_write(void*, void**) --- > void *llvm_gc_read(void*, void **)<br> > void llvm_gc_write(void*, void *, void**) 356,357c358 < implement it. Note that we may add a pointer to the start of the memory object < as a parameter in the future, if needed. --- > implement it. Index: ll...

...GCInterface.h =================================================================== RCS file: /var/cvs/llvm/llvm/runtime/GC/GCInterface.h,v retrieving revision 1.2 diff -r1.2 GCInterface.h 41c41 < void *llvm_gc_read(void **P); --- > void *llvm_gc_read(void **P, unsigned Offset); 46c46 < void llvm_gc_write(void *V, void **P); --- > void llvm_gc_write(void *V, void **P, unsigned Offset); Index: llvm/runtime/GC/SemiSpace/semispace.c =================================================================== RCS file: /var/cvs/llvm/llvm/runtime/GC/SemiSpace/semispace.c,v retrieving revision 1.4 diff -r1.4 se...

Couple of questions: 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) I haven't seen an adequate explanation of these, but I'm guessing: void *V: value being written to the field void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr upon entry to llvm_gc_write) void **FieldPtr: address of the field be...

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In

...along that type information to llvm.gcroot. And since the type of each pointer field is also known, the type information can be determined for each traced object, as long as there is no polymorphism. However, what I don't understand is how this works in the presence of write barriers. The llvm_gc_write intrinsic takes no type information, so there's no way to determine the type of the object except with a tag. So I'm not sure what exactly the write barrier can accomplish. Note that in a real language, most objects would have type tags, but there would be a significant number of object...

Hi Terence, I think you're getting hung up on the details of the shadow stack collector. The shadow stack is a GC that is possible within this framework, but of course could be implemented without any special support. Its presence is more misleading than anything else. Taking a step back, the concepts are: llvm.gcroot instructs the code generator --> My GC needs to be able to

...> llvm.gcroot. And since the type of each pointer field is also > known, the type information can be determined for each traced > object, as long as there is no polymorphism. > > However, what I don't understand is how this works in the presence > of write barriers. The llvm_gc_write intrinsic takes no type > information, so there's no way to determine the type of the object > except with a tag. So I'm not sure what exactly the write barrier > can accomplish. > > Note that in a real language, most objects would have type tags, > but there would...

On Apr 20, 2008, at 6:52 PM, Gordon Henriksen wrote: > On 2008-04-20, at 21:05, Terence Parr wrote: > >> On Apr 20, 2008, at 5:36 PM, Gordon Henriksen wrote: >> >>> Since the semispace heap doesn't actually work (it's an example, >>> at best), I suggest you simply copy the stack visitor into your >>> project; it's only a dozen lines of

...also decrement the ref count of all pointers within * head, which places them in the 'scan' list. */ } } } /* We use no read barrier */ void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { return *FieldPtr; } /* write barrier to increment and decrement refcounts */ void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) { if (ObjPtr != V) { /* skip all this work if simply resetting the field */ void *obj = *FieldPtr; refcnt_dec(obj); *FieldPtr = V; refcnt_inc(V); } } /*===----------------------------------------------------------------------===** * FIX...

Again, sorry for the delay. :( On Thu, 9 Mar 2006, Sandro Magi wrote: > I've written a reference-counting garbage collector for LLVM, but I'm > still unclear on a few things. Cool! > The following piece of code that appears on > http://llvm.cs.uiuc.edu/docs/GarbageCollection.html is unclear: > > ;; As the pointer goes out of scope, store a null value into > ;;