search for: fieldptr

...wo 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/ http://nondot.org/sabre/

...; 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 reference fields by offset, rather than alloca'ing memory for each FieldPtr needed (to make sure...

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

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 = { sbyte, sbyte, int* } > >...

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 > barriers do nothing. Also, there's nothing special about the > llvm_gc_rea...

...c_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 llvm_gc_allocate. Up to this point I feel pretty good about what's goi...

...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's nothing special about the llvm_gc_read or llvm_gc_write functions any mo...

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 being written 2. The current semispace c...

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 **FieldPtr: address of the field being written...

...ots 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 instruction: > > > &gt...

...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 >> barriers do nothing. Also, there's nothing special about th...

...ue TreeToLLVM::EmitLV_COMPONENT_REF( // Compute the byte offset, and add it to the pointer. unsigned ByteOffset = NumAlignmentUnits*ByteAlignment; + LVAlign = MinAlign(LVAlign, ByteOffset); Constant *Offset = ConstantInt::get(TD.getIntPtrType(), ByteOffset); FieldPtr = CastToType(Instruction::PtrToInt, FieldPtr, @@ -6242,17 +6282,18 @@ LValue TreeToLLVM::EmitLV_COMPONENT_REF( // Okay, everything is good. Return this as a bitfield if we can't // return it as a normal l-value. (e.g. "struct X { int X : 32 };" ). + // Conservativ...

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 being written 2. The current semispace c...

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_write) > > void **FieldPtr: addres...

...r (; 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); *FieldPtr = V; refcnt_inc...

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

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

On Wed, 21 Jul 2004, Chris Lattner wrote: > > Yes, this makes a tremendous amount of sense. Do you think you could > prepare some patches to make this happen? If you have any questions, feel > free to ask :) Ok, a patch[1] is attached. I didn't care to coerce the offset, since I assume that it is an uint, but maybe I should? Hopefully I've understood the llvm source

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