> 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>