[LLVMdev] GC questions.

[Tobias Nurmiranta]

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* }
>
>   %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/
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>