<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jul 6, 2011, at 3:24 PM, Talin wrote:</div><br><blockquote type="cite"><div><div><div><span style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px"><b>Overall Proposal: Support marking SSA values as roots (an evolutionary approach)</b></span><div style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px">
<br></div><div style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px">My proposal consists of three rather significant changes to LLVM:</div><div><ul><li><font face="arial, sans-serif"><span style="border-collapse:collapse">Allow frontends to mark SSA values - or even portions of SSA values - as stack roots.</span></font></li>
<li><font face="arial, sans-serif"><span style="border-collapse:collapse">For alloca roots, add a way to communicate to LLVM when a root goes out of scope.</span></font></li>
<li><font face="arial, sans-serif"><span style="border-collapse:collapse">Transfer the responsibility for copying stack roots to memory, from the frontend to the LLVM code generators.</span></font></li>
</ul></div><div style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px">Let me take the last point first.</div><div style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px">
<br></div><div style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px"><b>Proposal Pt 3: </b><b>Copying Stack Roots to Memory</b></div><div style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px">
<br></div><div style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px">The LLVM code generators and analysis passes have a much more thorough knowledge of SSA value lifetimes than frontends do, and therefore could avoid spilling and reloading of values when it wasn't needed. So the LLVM libraries should take over the job of creating local allocas for holding SSA values during a safe point, as well as the job of copying those SSA values to those allocas.</div>
<div style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px"><br></div><div style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px">Of course, generating "optimal" code (as outlined in the previous section) would require a lot of work to the backends. But we don't need to do that right away. The first goal should be a "conservative, pessimistic" implementation that's no better or worse than what we have today (other than being far easier to use.) It might be possible to do this as some sort of stand-alone transformation/lowering pass.</div>
<div style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px"><br></div><div style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px">This is what I mean by an evolutionary approach - come up with the right interface between the frontends and LLVM that enables us to gradually move towards that eventual goal.</div></div></div></div></blockquote><br></div><div>The initial step of your evolutionary approach sounds basically equivalent to what is possible today. When you try to go beyond that you will run into a lot of issues, since the backend is untyped and doesn't even distinguish between pointers and integers. The closest thing we have to tracking liveness of SSA values throughout the backend is debug info, which is frequently incorrect (although usually not due to the code generator itself).</div><div><br></div><div>Who is going to implement support for all of this in the code generator passes and maintain it? Will GC compatibility be a requirement for any further improvements in code generation?</div><div><br></div><div>Cameron</div></body></html>