[LLVMdev] llvm.gcroot suggestion

nicolas geoffray nicolas.geoffray at gmail.com
Mon Feb 21 01:50:43 PST 2011


Hi Talin,

On Fri, Feb 18, 2011 at 5:50 PM, Talin <viridia at gmail.com> wrote:
>
>
> In the current scheme, the way you tell LLVM that a root is no longer
> needed is by assigning NULL to it. However, that assumes that all roots are
> pointers, which is not true in my world - a root can be a struct containing
> pointers inside of it. (In my current frontend, a non-pointer root is
> indicated by passing a non-NULL metadata argument to llvm.gcroot, which
> contains information about which fields in the struct are roots. This is
> especially important in the case of tagged unions, where the garbage
> collector may have to examine the union tag field in order to determine if
> the pointer field is indeed a pointer - passing the pointer alone would be
> insufficient to determine this.)
>

For a tagged union, I guess you are currently using the second argument of
llvm.gcroot to provde the information? I guess keeping an intrinsic for this
kind of code is the best way to go.


> Putting GC roots in a different address space works OK for me, as long as I
> can have SSA values that are structs that have pointers embedded in them
> that are in this different address space. In other words, if I have an SSA
> value that is a struct containing pointers which are roots, I need for the
> garbage collector to see the entire struct, not just the pointers.
>

That's entirely fine with a different address space. The roots given by the
LLVM GC pass should contain the location of these embedded pointers.


>
> What I'm primarily asking for is to have the LLVM code generator
> automatically spill roots from SSA values to memory during a sync point, and
> reload them afterward,
>


I don't think that's even needed: long term, LLVM should return the location
of all roots for a given sync point (typically method call). By all roots, I
mean register roots and stack roots. The frontend should then be responsible
for updating those roots.


> instead of my frontend having to generate code to do this. As I mentioned,
> the current scheme results in the frontend having to generate very
> inefficient IR because of the need to be conservative about root liveness.
>

Agree.


> The frontend can't know anything about the optimization passes that LLVM
> will perform on the function.
>

Sure. And I think the way to go is to remove the llvm.gcroot intrinsic (and
the hackish way it currently works: right now, because we take the address
of the alloca, the LLVM optimiziers won't try to optimize an alloca that may
escape through the llvm.gcroot function call). By having an address space
for GC roots, optimizers don't need to care about anything. After the
optimizers and the register allocator, a final LLVM pass should compute the
root lists of all sync points.

Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110221/550d783d/attachment.html>


More information about the llvm-dev mailing list