[LLVMdev] GC questions.

[Chris Lattner]

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/