On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:> [1] I'm kind of newbie of cvs, but I did: > "cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm diff llvm > gcpatch"That patch is well formed. You did exactly the right thing. :)> 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 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/ http://nondot.org/sabre/
On Wed, 21 Jul 2004, Chris Lattner wrote:> On Wed, 21 Jul 2004, Tobias Nurmiranta 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 reference fields by offset, rather than alloca'ing memory for each FieldPtr needed (to make sure the recording of gcroots is sound). If we use FieldPtr we get the problem again with the GC traversing pointers into objects, rather than to their headers. Or have I missed something? :) , Tobias
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* %pairPtr, int 0, uint 2 FieldVal = llvm.gc_read(pairptr, fieldptr) Because of the getelementptr instruction is used, we don't have the explicit offset encoded into the bytecode file. The other advantage of this is that when the gc_read/write intrinsics are lowered to load/stores, the resultant LLVM code will be much simpler.> 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 the recording of gcroots is sound). If we > use FieldPtr we get the problem again with the GC traversing pointers into > objects, rather than to their headers.You're right, but you shouldn't need to put the inner pointer into an alloca. The idea is that the GC will (eventually) only stop a thread at a GC safe point, so heap-directed pointers that don't live across a safe point can live in an LLVM register. Currently function calls are the only safe points, though we will add an explicit gc.safepoint intrinsic when we get threads (to put safe points in loops and other places that don't have calls). Since field accesses like this are all very short lived, they can all just be registers. -Chris -- http://llvm.cs.uiuc.edu/ http://nondot.org/sabre/