[LLVMdev] JVM Backend

[David Roberts]

> So it will stack overflow on tail calls
At the moment, yes. But then again, so does java. Also, it looks like
they're working on support for tail calls in the Da Vinci Machine[1].

> and break with run-time errors
When I said it raises an assertion, I meant at compile-time.

> on structs?
No, structs are supported. The only unsupported types at the moment
(as far as I am aware) are things like i31 and f80.

> I would love to be able to evaluate LLVM IR in a safe environment (like the
> JVM) for debugging purposes but this is too incomplete to be useful for me:
> my IR depends heavily upon tail calls and value types. Unfortunately, the
> MSIL backend and lli are also incomplete and, therefore, useless for me too.
>
> As Chris said, the LLVM world really needs any fully working solution rather
> than a selection of incomplete solutions.
I haven't been working on this project for too long - you can't expect
it to be perfect on the first release.

[1] http://openjdk.java.net/projects/mlvm/subprojects.html#TailCalls

--
David Roberts
http://da.vidr.cc/



On Sun, Nov 29, 2009 at 09:49, Jon Harrop <jon at ffconsultancy.com> wrote:
> On Saturday 28 November 2009 06:20:39 David Roberts wrote:
>> > How do you handle tail calls and value types?
>>
>> I haven't worried too much about optimisation yet, so it doesn't do
>> anything special for tail calls (although neither does the java
>> compiler). LLVM types are translated to their equivalent java
>> primitive type (or currently it raises an assertion if there is no
>> equivalent type).
>
> So it will stack overflow on tail calls and break with run-time errors on
> structs?
>
> I would love to be able to evaluate LLVM IR in a safe environment (like the
> JVM) for debugging purposes but this is too incomplete to be useful for me:
> my IR depends heavily upon tail calls and value types. Unfortunately, the
> MSIL backend and lli are also incomplete and, therefore, useless for me too.
>
> As Chris said, the LLVM world really needs any fully working solution rather
> than a selection of incomplete solutions.
>
> --
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>