[LLVMdev] JVM Backend

Chris Lattner clattner at apple.com
Thu Nov 26 21:27:36 PST 2009


On Nov 26, 2009, at 4:57 PM, David Roberts wrote:
>> Who is the expected client of this code?
> There are several reasons why compiling to JVM bytecode can be
> desirable. For example, it can be executed on platforms that do not
> support native code execution for security or other reasons e.g.
> browser applets, mobile devices, some webhosts. From the Java
> perspective, it allows libraries written in languages such as C to be
> used in a cross-platform manner, without the need for reliance on a
> native library through JNI.

That's all fine, if it actually works.  Supporting the full generality of LLVM IR is imperative if you want to achieve that goal, and I'm not sure how you do that.

>> Will it be maintained going forward?
> I can't guarantee anything, but I'll do my best to keep it maintained.
> 
>> Is it going to cover the full generality of LLVM IR constructs?
>> How do you plan to handle unsafe IR?
> Sorry, I'm still relatively new to LLVM, so I'm not sure what you're
> refering to.

How does your code handle non-type-safe C code?  How does it translate it to type-safe java code?  If you translate to a big array of memory and index into it, how is it better than the mips -> java compiler?

> If this patch is not to be included in the LLVM source tree, then is
> it possible to distribute backends as standalone tools?

Sure, you can use 'llc -load foo.so' to dynamically load backends.

-Chris



More information about the llvm-dev mailing list