Hi Joachim,<br><br><div class="gmail_quote">On Sat, Aug 27, 2011 at 12:10 PM, Joachim Durchholz <span dir="ltr"><<a href="mailto:jo@durchholz.org">jo@durchholz.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Sorry if I'm repeating something that was already said.<br>
<br>
I was just thinking "why the heck do I seem headed for JVM generation if<br>
what I want to use is LLVM", and this is the result:<br>
<br>
I'm coming from a Java background. I'm using Eclipse, I'm used to the<br>
syntax highlighting, cross referencing and refactoring support that<br>
Eclipse offers.<br>
I know I will want to have the same infrastructure for my language, and<br>
I want it written in my language. I WILL need a JVM backend, no matter what.<br>
<br>
Now, I'd still love to use LLVM. It has a lot to offer for the phases<br>
"above" code generation. I don't need register allocation, but I'd like<br>
to make use of common constant elimination, loop unrolling, inlining, or<br>
the pass management infrastructure; that's a whole lot of code I don't<br>
need to write.<br>
And when it comes to generating raw machine code, I can confidently say:<br>
develop in Eclipse and run the stuff as JVM code, but deploy using the<br>
machine-code backend provided by LLVM.<br>
<br>
So my conclusion is:<br>
To make LLVM attractive for us Java-based language designers, we need<br>
the means to write a JVM backend.<br>
The actual backend is easy, libraries for class file and JAR generation<br>
exist.<br>
I'd need help for:<br>
* Determining where exactly the line is drawn between "this LLVM<br>
component is useful for JVM bytecode generation" and "this LLVM<br>
component isnt". (Constant folding would be, register allocation would<br>
not, but there's a lot of gray areas between these two.)<br></blockquote><div><br></div><div>I guess the existing line between opt/llc is similar to yours. You're just interested in llvm bitcode optimizations that produce a different, hopefully optimized bitcode. That's what the "opt" binary does. Register allocation is target specific and does not "produce" any bitcode.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
* Not being a JNI or C++ expert, building the JNI infrastructure that<br>
would allow calling LLVM components from Java.<br>
* Not being a true Eclipse expert, wrapping LLVM binaries as Eclipse<br>
plugins. Eclipse expects plugins to be available for download via HTTP,<br>
with some XML that describes dependencies. Setting this up would be<br>
easy, getting the details right would be work.<br>
<br>
That's just my specific skillset, other language designers might have<br>
different ones, but I guess it is not very likely that the exact right<br>
combination will come up easily. There aren't many people around who're<br>
experts in C++, Java, and Eclipse.<br>
<br>
Oh, and the question I'm having is: Is LLVM for me?<br>
<br>
Regards,<br>
Jo<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>