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

</div></blockquote><div><br></div></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></blockquote><div><br></div><div>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.</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>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></blockquote><div><br></div><div>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.</div><div> </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>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, </div></div></blockquote><div><br>
</div><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>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.</div>
</div></blockquote><div><br></div><div>Agree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>The frontend can't know anything about the optimization passes that LLVM will perform on the function.</div>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Nicolas</div></div>