search for: llvm_gc_read

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

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 = ... %fi...

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 could use the getelementptr instruction: > > %pairty = { s...

...all to > llvm_gc_allocate. 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 d...

...rstood > the llvm source correctly. This will work, but it would be better to take two pointers in instead of a pointer and offset. This allows the front-end to emit target-generic code instead of target-specific code (where it would have to know the offset to the field). To be more specific, llvm_gc_read should look like this by default: void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { return *FieldPtr; } Also, please don't forget to update docs/GarbageCollection.html and LangRef.html Thanks for the help, sorry I didn't mention this before. :) -Chris -- http://llvm.cs.uiuc.edu/...

...rates LLVM IR code 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 ge...

.../utils/fpcmp/Depend Index: llvm/lib/Transforms/Scalar/LowerGC.cpp =================================================================== RCS file: /var/cvs/llvm/llvm/lib/Transforms/Scalar/LowerGC.cpp,v retrieving revision 1.4 diff -r1.4 LowerGC.cpp 112c112 < GCRead = M.getOrInsertFunction("llvm_gc_read", VoidPtr, VoidPtrPtr, 0); --- > GCRead = M.getOrInsertFunction("llvm_gc_read", VoidPtr, VoidPtrPtr, Type::UIntTy, 0); 115c115 < VoidPtr, VoidPtrPtr, 0); --- > VoidPtr, VoidPtrPtr, Type::UIntTy, 0);...

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

...ntrinsic, which hides how the gcroots are implemented. , Tobias On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > 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 could use the getelementptr i...

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

...miranta wrote: > > This will work, but it would be better to take two pointers in instead of > a pointer and offset. This allows the front-end to emit target-generic > code instead of target-specific code (where it would have to know the > offset to the field). To be more specific, llvm_gc_read should look like > this by default: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > return *FieldPtr; > } Hm, but doesn't FieldPtr need to be calculated target-specific in those cases? My thoughts was that it's better to just have one pointer to the heap, and re...

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

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

...he list of deferred refs */ for (; head != NULL; head = head->field.next) { free(head); /* FIXME: this should 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);...

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