On Thu, Jul 7, 2011 at 2:25 PM, Cameron Zwarich <span dir="ltr"><<a href="mailto:zwarich@apple.com" target="_blank">zwarich@apple.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">
<div style="word-wrap:break-word"><div><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><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></blockquote><div>That's really the key question. Most of the developers who are paid to work on LLVM are doing so in support of Clang, which doesn't need this feature. And language experimenters generally don't have time to work on their own language and at the same time become familiar enough with the LLVM code generator passes to do useful work.</div>
<div><br></div><div>It's kind of a chicken and egg problem: Managed language creators aren't attracted to LLVM because it lacks certain features - they are far more likely to choose the JVM as a development platform (as seen in the case of Scala, Groovy, and many others). Conversely, the lack of customers for those features in LLVM makes it difficult to justify putting significant effort into building and maintaining them. This is what I meant when I said that the LLVM community lacks momentum in certain areas.</div>
<div><br></div><div>However, what I'm attempting to do is at least get some sort of consensus on what we'd *like* to have happen, even if we don't yet have someone available to do the work. If some GSoC student showed up tomorrow and volunteered to do all this, I don't think we'd be in agreement as to what we'd want them to do.</div>
<div><br></div><div>I would say that first and foremost, let's come up with some scheme that allows types, rather than values, to be marked as roots, and which doesn't impose a huge cost on users that don't need GC. Pretty much everything else is contingent on that. I suggested several approaches, but I'm sure that there are people on this list who have much better ideas than mine.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>
</div><font color="#888888"><div>Cameron</div></font></div></blockquote></div><br><br clear="all"><br>-- <br>-- Talin<br>