[LLVMdev] Re: Newbie questions

Vikram Adve
Wed, 26 Apr 2006 19:42:05 -0000

On Apr 26, 2006, at 10:45 AM, Tom Tromey wrote:

>>>>>> "Vikram" == Vikram Adve <vadve at
cs.uiuc.edu> writes:
>
> Vikram> Either way, one issue that you will have to deal with is
> preserving
> Vikram> the behavior of Java exceptions (assuming you care about
> that).  LLVM
> Vikram> does not preserve the order of potentially excepting
> instructions
> Vikram> (e.g., a divide or a load).  This would have to be handled
> Vikram> explicitly, whether you use llvm-java or simply used LLVM
> on the C
> Vikram> code from Soot.  I don't know if/how libgcj handles this
> but Tom may
> Vikram> be able to say more about that.
>
> libgcj has two different approaches.
>
> On some platforms we generate explicit checks for null pointer
> dereferences and for division by zero (division is a bit different in
> that we also have to handle java's special rule for dividing -1 by the
> minimum integer -- I think most platforms actually call the helper
> function).
>
> On other platforms, we don't generate explicit checks but instead let
> them signal, and then we have special code in the runtime to turn a
> signal into an exception.  The second part here is that GCC knows
> about implicitly trapping instructions (the -fnon-call-exceptions
> flag, which we pass to all compilations for these targets).

Ok, this makes sense.  But I was actually asking how you deal with
this in the LLVM JIT for libgcj (I guess it is too early for you to
have an answer).

Specifically, I don't think either of these approaches will be
sufficient when using LLVM as a JIT in libgcj.  In either case, an
LLVM optimization could still reorder trapping instructions.  In the
first approach, this is less likely to occur but is possible.  The
second approach of course wouldn't work because LLVM doesn't have a
notion of implicitly trapping instructions and could merrily reorder
such operations.

What are your plans for the LLVM JIT?  It would be quite valuable to
have a JVM-bytecode front end for LLVM.  At this point, llvm-java
development has been suspended for some time and I don't think it
makes sense to put effort into two different front-ends if we can
avoid it.