Hi,
I've written a backend for LLVM that allows LLVM IR to be transformed
to a Java/JVM class file (llvm-jvm.patch.gz attached).
Indirect function calls don't work yet, and there's probably some
minor bugs in it, but it works well for the test cases that I've run
through it. Also, several instructions are emulated by method calls
due to deficiencies in the JVM instruction set (e.g. lack of unsigned
arithmetic), so performance could also be improved in this area
(although the JVM should inline the calls when it feels it necessary).
In order to link and run the output, the LLJVM[1] runtime is required,
which is essentially a compatibility layer allowing things such as
pointers to be used (emulated) within the JVM. Jasmin[2] is also
required to assemble the output code.
In order to transform LLVM IR to a class file and run it, the
following process is required:
llc -march=jvm foo.bc -o foo.j
# link references to external functions/variables with
# a basic I/O class and the Java math library
java -jar path/to/lljvm.jar ld BasicIO java.lang.Math < foo.j >
foo.linked.j
mv -f foo.linked.j foo.j
# assemble
java -jar path/to/jasmin.jar foo.j
# run
java -classpath path/to/lljvm.jar:. foo
At the moment only very basic I/O is available (attached
BasicIO.{java,class}) due to the lack of the C Standard Library.
Before I go reinventing the wheel, has anyone had any luck with
compiling a libc implementation (e.g. newlib) to LLVM IR (without any
platform-dependent inline assembly, etc)?
What is the process for requesting this patch be applied to the LLVM
source tree?
[1] Homepage: http://da.vidr.cc/projects/lljvm/
Download: http://lljvm.googlecode.com/files/lljvm-0.1.jar
[2] http://jasmin.sf.net/
--
David Roberts
http://da.vidr.cc/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-jvm.patch.gz
Type: application/x-gzip
Size: 13136 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20091124/74d9cc00/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BasicIO.class
Type: application/octet-stream
Size: 1040 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20091124/74d9cc00/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BasicIO.java
Type: text/x-java
Size: 1036 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20091124/74d9cc00/attachment.java>
Hello, David First of all, thanks for the backend submission. I let Chris comment about the procedure of adding it to the tree. :) I just did a quick look into the code. The comments are below> Indirect function calls don't work yet, and there's probably some > minor bugs in it, but it works well for the test cases that I've run > through it.Could you please provide some sort of "feature" test? So, we might be sure that the stuff won't be broken due to e.g. some API change, etc. Now we have a powerful FileCheck facility, so, you might just have a one .ll file and check for the JVM code emitted.> In order to link and run the output, the LLJVM[1] runtime is required,Can this be documented somehow? E.g. in a readme file in the backend dir, etc? It will be nice if this library be somehow integrated into LLVM as well. The current big question is: how you're planning to deal with arbitrary precision stuff which might come from LLVM IR. Currently all the things seems to behave different in case of receiving e.g. i31: - functions like getTypeName() return some junk (the case Type::IntegerTypeID just falls through to Type::FloatTyID) - other functions just assert -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
> Could you please provide some sort of "feature" test? So, we might be > sure that the stuff won't be broken due to e.g. some API change, etc. > Now we have a powerful FileCheck facility, so, you might just have a > one .ll file and check for the JVM code emitted.Additional patch attached, is this suitable?>> In order to link and run the output, the LLJVM[1] runtime is required, > Can this be documented somehow? E.g. in a readme file in the backend > dir, etc?I can do that.> The current big question is: how you're planning to deal with > arbitrary precision stuff which might come from LLVM IR.I should be able to implement that. Would arbitrary precision support be required for the initial commit of the backend?> Currently all > the things seems to behave different in case of receiving e.g. i31: > - functions like getTypeName() return some junk (the case > Type::IntegerTypeID just falls through to Type::FloatTyID)getBitWidth raises an assertion before this can happen. -- David Roberts http://da.vidr.cc/ On Wed, Nov 25, 2009 at 21:03, Anton Korobeynikov <anton at korobeynikov.info> wrote:> Hello, David > > First of all, thanks for the backend submission. I let Chris comment > about the procedure of adding it to the tree. :) > > I just did a quick look into the code. The comments are below > >> Indirect function calls don't work yet, and there's probably some >> minor bugs in it, but it works well for the test cases that I've run >> through it. > Could you please provide some sort of "feature" test? So, we might be > sure that the stuff won't be broken due to e.g. some API change, etc. > Now we have a powerful FileCheck facility, so, you might just have a > one .ll file and check for the JVM code emitted. > >> In order to link and run the output, the LLJVM[1] runtime is required, > Can this be documented somehow? E.g. in a readme file in the backend > dir, etc? It will be nice if this library be somehow integrated into > LLVM as well. > > The current big question is: how you're planning to deal with > arbitrary precision stuff which might come from LLVM IR. Currently all > the things seems to behave different in case of receiving e.g. i31: > - functions like getTypeName() return some junk (the case > Type::IntegerTypeID just falls through to Type::FloatTyID) > - other functions just assert > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University >-------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-jvm-test.patch.gz Type: application/x-gzip Size: 890 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091126/82d72ebf/attachment.bin>