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/
>>>>> "Vikram" == Vikram Adve <vadve at cs.uiuc.edu> writes:Vikram> Ok, this makes sense. But I was actually asking how you deal with Vikram> this in the LLVM JIT for libgcj (I guess it is too early for you to Vikram> have an answer). Yeah. I completely punted on exception handling in general, since at the moment there is really no hope for integrating it into libgcj :-( I did look at writing little trampoline functions for calls into and out of LLVM-compiled code ... but that still fails when we take stack traces, and these traces are essential in some situations. So until this is fixed the JIT for libgcj is more or less an experimental toy. Vikram> Specifically, I don't think either of these approaches will be Vikram> sufficient when using LLVM as a JIT in libgcj. In either case, an Vikram> LLVM optimization could still reorder trapping instructions. I don't know what to do -- you tell me :-) It sounds like LLVM needs some way for its users to express this sort of thing. Vikram> What are your plans for the LLVM JIT? It would be quite valuable to Vikram> have a JVM-bytecode front end for LLVM. At this point, llvm-java Vikram> development has been suspended for some time and I don't think it Vikram> makes sense to put effort into two different front-ends if we can Vikram> avoid it. I'm going to keep developing it as an add-on for libgcj. Hopefully I'll be able to distribute it in FC6 or FC7. Last night I found a huge, glaring bug in my JIT (so huge that I don't really know how I could have missed it before) that will require a fair bit of surgery. I'll be fixing that this week. Once I've stabilized things a bit I will check in the needed libgcj patch so that the JIT doesn't require a custom gcc build in order to be plugged in. For the time being I'm only interested in having it work in libgcj. But, I agree, duplicating effort doesn't make sense. If there's a way to generalize it to work in other environments, I'm open to it. Tom
On Wed, 26 Apr 2006, Vikram Adve wrote:>> 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).> 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.Vikram, I'm confused. How do you think LLVM will break this? It will never introduce a trapping operation on a path without a trap, and the approach above doesn't require the ability to distinguish between traps: in fact, any trap would be a fatal error. Please explain specifically what you think is an issue, so I can understand. Thanks, -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Apr 26, 2006, at 3:06 PM, Tom Tromey wrote:> So until this is fixed the JIT for libgcj is more or less an > experimental toy.Ok, I understand, though it is unfortunate. I don't have any great insights into fixing this.> I'm going to keep developing it as an add-on for libgcj. > Hopefully I'll be able to distribute it in FC6 or FC7. > > Last night I found a huge, glaring bug in my JIT (so huge that I > don't really know how I could have missed it before) that will > require a fair bit of surgery. I'll be fixing that this week. > > Once I've stabilized things a bit I will check in the needed libgcj > patch so that the JIT doesn't require a custom gcc build in order to > be plugged in. > > For the time being I'm only interested in having it work in libgcj. > But, I agree, duplicating effort doesn't make sense. If there's a way > to generalize it to work in other environments, I'm open to it.I would be quite happy to use libgcj directly, once the LLVM JIT is more functional. I think there are a lot of interesting projects that could be done with that alone. Regards, --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/
On Apr 26, 2006, at 3:23 PM, Chris Lattner wrote:> On Wed, 26 Apr 2006, Vikram Adve wrote: >>> 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). > >> 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. > > Vikram, I'm confused. How do you think LLVM will break this?By reordering two instructions that could throw exceptions.> It will never introduce a trapping operation on a path without a trap,That isn't required to break it as above.> and the approach above doesn't require the ability to distinguish > between traps: in fact, any trap would be a fatal error.I'm talking about non-fatal conditions like divide-by-0 or a null reference that are caught by exception handlers. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/
On Apr 26, 2006, at 2:42 PM, Vikram Adve wrote:>> 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.Just a correction, for the record: The first approach should work, i.e., the two trapping instructions will not be reordered by LLVM opts (unless the reordering was harmless even if the exceptions occur, e.g., if the handlers were inlined and had no side-effects).> 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.That is still correct. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/