<div class="gmail_quote">On Wed, Jul 6, 2011 at 9:04 AM, Geoff Reedy <span dir="ltr"><<a href="mailto:geoff@programmer-monk.net">geoff@programmer-monk.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Fri, Jul 01, 2011 at 11:05:44AM -0700, Talin said<br>
<div class="im">> So I've been using LLVM for about 4 years now, and I've posted a lot on this<br>
> list about specific issues. What I would like to do is step back for a<br>
> moment and give my "big picture" assessment of LLVM overall, particularly<br>
> with respect to developing a "managed" language like Java / C# or my own<br>
> language, Tart.<br>
<br>
</div>I'm working on an LLVM backend for the Scala compiler[1], so I'm very<br>
interested in the issues you discuss here. Some of them I have<br>
encountered myself already and others I can see on the horizon. I am new<br>
to the list and offer apologies and request pointers if I cover ground<br>
that's been trodden before.<br>
<br>
[1] <a href="http://greedy.github.com/scala/" target="_blank">http://greedy.github.com/scala/</a><br>
<div class="im"><br>
> I would also like to list the areas where I *don't need help* from LLVM -<br>
> that is, these are things I can easily handle myself in the frontend:<br>
><br>
> - Dynamic dispatch and virtual methods / multi-methods<br>
> - Boxing and unboxing of value types<br>
> - Reflection<br>
> - Memory management<br>
><br>
> I mention these items for two reasons: First, because these are services<br>
> that *would* be provided by a JVM, and I want people to know that the lack<br>
> of these items in LLVM does not in any way count as a detriment. And<br>
> secondly, because I've occasionally heard people on this list ask for<br>
> features like these, and I think it would be a waste of time to spend effort<br>
> implementing something that the frontend can easily handle.<br>
<br>
</div>Agree 100%.<br>
<div class="im"><br>
> The rest of my issues are more specific:<br>
><br>
> *Garbage collection is still way too difficult*. The biggest problem is the<br>
> inability to track SSA values - it requires the frontend to generate very<br>
> inefficient and error-prone code, manually spilling SSA values to the stack<br>
> around nearly every function call. I've written proposals for improving the<br>
> situation, which I won't repeat here - but realistically there's no way that<br>
> I am ever going to have time learn to enough about LLVM's code generation<br>
> passes to implement something like this myself.<br>
<br>
</div>I'd appreciate a pointer to the previous proposal and discussion. I<br>
assume that you're talking about automatic spilling of SSA roots to<br>
stack slots at safe points? Is it possible that you could attach<br>
metadata to these SSA values and generate the appropriate LLVM IR to<br>
spill all the values that dominate the safe point in the GC strategy?<br>
<div class="im"><br></div></blockquote><div>Actually, my ideas have changed somewhat, so I'll start a new thread with the most recent incarnation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
> Another area which I'd like to see supported is stack walking - that is,<br>
> starting from the current call frame, iterate through all of the call frames<br>
> above it. Currently the only way to do this is via platform-specific<br>
> assembly language - I'd think it would be relatively simple to make an<br>
> intrinsic that does this. (Note that the current stack intrinsics are<br>
> unusable, because they are (a) unreliable, and (b) inefficient. Taking an<br>
> integer index of a stack frame as a parameter is not the right way to do<br>
> it.)<br>
<br>
</div>Do you have something in mind similar to the interface provided by<br>
libunwind (<a href="http://www.nongnu.org/libunwind/docs.html" target="_blank">http://www.nongnu.org/libunwind/docs.html</a>) but lighter weight<br>
and integrated with LLVM?<br>
<div class="im"><br></div></blockquote><div>You're in luck - I happen to have a document that explains this very thing:</div><div><br></div><div><a href="https://docs.google.com/document/pub?id=1-ws0KYo47S0CgqpwkjfWDBJ8wFhW_0UYKxPIJ0TyKrQ">https://docs.google.com/document/pub?id=1-ws0KYo47S0CgqpwkjfWDBJ8wFhW_0UYKxPIJ0TyKrQ</a></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> I have to say, if there's any single issue that could make me give up on<br>
> LLVM and switch over to using something like a JVM, it would be this -<br>
> because as far as I can tell, LLVM's garbage collection features are in<br>
> exactly the same state they were in when I started working with LLVM four<br>
> years ago.<br>
<br>
</div>In my mind one of the frustrations trying to use the GC support in LLVM<br>
is the somewhat sketchy documentation. I'd be nice to have a<br>
straightforward end-to-end example. Since you've implemented a GC using<br>
this support maybe you could write something up. I know I'd appreciate<br>
it a lot. Do you find that the status table in the GC document is still<br>
accurate? It seems like the features you'd like to see implemented most<br>
here are<br>
<br>
- Emitting code at safe points<br>
- Register maps<br>
- Liveness analysis (it appears that the new lifetime intrinsics may<br>
enable this)<br>
<br>
> *Platform ABI limitations* - Currently LLVM requires the frontend developer<br>
<div class="im">> to know quite a lot about the platform ABI - for example whether you are<br>
> allowed to pass a struct of a certain size as a value type rather than as a<br>
> reference. The thing is, experimental languages like mine generally don't<br>
> care so much about ABI compatibility - sure, we'd like to be able to call C<br>
> library functions once in a while (and we don't mind doing the extra work in<br>
> those cases), but most of the time we just want to pass a data type around<br>
> and expect it to work. Requiring the use of different techniques on<br>
> different platforms makes the situation considerably more complex.<br>
<br>
</div>Is it reasonable to add a new calling convention that like fastcc<br>
doesn't need to worry about conforming to any ABI but instead of trying<br>
to go fast, provides maximum flexibility?<br>
<br></blockquote><div>I'll have to defer to the experts on this one.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> *Light-weight coroutines* would be a "nice to have", as would better<br>
<div class="im">> *concurrency<br>
> primitives*. These are things I could do on my own, but it would be better,<br>
> I think, to have them in LLVM - because in my view of the world, anything<br>
> that requires lots of architecture-specific knowledge ideally belongs on the<br>
> LLVM side of the line.<br>
><br>
> There's been a lot of discussion about divide-by-zero errors and other<br>
> *non-declared<br>
> exceptions*. Having this available would be a great help.<br>
<br>
</div>Agreed. I have read some of the proposals about this and it does indeed<br>
seem tricky. At the least the instructions that could raise an exception<br>
would have to be marked in some way so that side-affecting code isn't<br>
moved past them.<br>
<br></blockquote><div>There have been a couple of proposals put forward, but nothing has materialized yet. Here is one:</div><div><br></div></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div class="gmail_quote"><div><a href="http://code.google.com/p/llvm-stack-switch/wiki/Proposal">http://code.google.com/p/llvm-stack-switch/wiki/Proposal</a></div></div></blockquote><div class="gmail_quote"><div><br></div>
<div>There's also this thread:</div><meta charset="utf-8"><div><br></div></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div class="gmail_quote"><div><a href="http://comments.gmane.org/gmane.comp.compilers.llvm.devel/38987">http://comments.gmane.org/gmane.comp.compilers.llvm.devel/38987</a></div>
</div></blockquote><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> > *Named structure types* - as per Chris's proposal - would be a major<br>
<div class="im">> simplification, as it would allow declaration of pointer fields without<br>
> having to import the code that defines the structure of the thing that the<br>
> pointer is pointing to.<br>
<br>
</div>I would really like to see this. It would also help when inspecting IR.<br>
Right now if types have been uniqued all structures with the same layout<br>
get collapsed to a single name which makes things awkward to read.<br>
<br></blockquote><div>Yep!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
-- Geoff<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">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>
</blockquote></div><br><br clear="all"><br>-- <br>-- Talin<br>