On Fri, Feb 18, 2011 at 1:05 AM, nicolas geoffray <span dir="ltr"><<a href="mailto:nicolas.geoffray@gmail.com">nicolas.geoffray@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Hi Talin,<br><br><div class="gmail_quote"><div class="im">On Fri, Feb 18, 2011 at 1:36 AM, Talin <span dir="ltr"><<a href="mailto:viridia@gmail.com" target="_blank">viridia@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Thinking about it even more, here's a short summary of what I would propose:<div><ul><li><b>llvm.gc.value</b>(value, metadata) - marks an SSA value as a garbage collection root. This remains in effect for the lifetime of the SSA value.</li>




<li><b>llvm.gc.declare</b>(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.</li><li><b>llvm.gc.undeclare</b>(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.</li>


</ul></div></blockquote><div><br></div></div><div>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.</div>

</div></blockquote><div><br></div><div>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.)</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">
<div><br></div><div>Cheers,</div><div>Nicolas</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><div><ul>

</ul><div>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.</div><div><br></div><div>-- </div>-- Talin<br>





</div>
<br></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br>
</blockquote></div><br><br clear="all"><br>-- <br>-- Talin<br>