[LLVMdev] llvm.gcroot suggestion

[Talin]

On Fri, Feb 18, 2011 at 1:05 AM, nicolas geoffray <
nicolas.geoffray at gmail.com> wrote:

> Hi Talin,
>
> On Fri, Feb 18, 2011 at 1:36 AM, Talin <viridia at gmail.com> wrote:
>>
>> Thinking about it even more, here's a short summary of what I would
>> propose:
>>
>>    - *llvm.gc.value*(value, metadata) - marks an SSA value as a garbage
>>    collection root. This remains in effect for the lifetime of the SSA value.
>>    - *llvm.gc.declare*(alloca, metadata) - marks an alloca as a garbage
>>    collection root. This intrinsic tells LLVM that it should start treating the
>>    alloca as a GC root from that point in the CFG onward.
>>    - *llvm.gc.undeclare*(alloca) - tells LLVM that the alloca should no
>>    longer be considered a GC root. If llvm.undeclare() is never called, then
>>    the alloca is treated as a root until the end of the function.
>>
>>
> I am unsure why you need to provide a live range for a gc root. It looks to
> me that LLVM should be able to compute it (considering GC allocas never
> escape). I think the reason why you want this intrinsic is to work around
> the current way a GC root is declared (an alloca in the first block), but it
> does not have to be that way. At some point, Chris suggested that we could
> put the GC root in a different address space than other pointers.
>

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.)

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.

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, 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. The frontend can't know anything about the optimization
passes that LLVM will perform on the function.


> Cheers,
> Nicolas
>
>
>
>>
>>
>> One other thing I thought of was that it would be convenient to declare
>> function parameters with llvm.gc.value(). However, I can get around not
>> having that as a feature.
>>
>> --
>> -- Talin
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>


-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110218/cf8a9344/attachment.html>