[LLVMdev] Re: Newbie questions

[Vikram Adve]

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.

--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/