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 Wed, 26 Apr 2006, Vikram Adve wrote:> 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.One of us is confused. The approach above never has instructions that throw exceptions.> I'm talking about non-fatal conditions like divide-by-0 or a null reference > that are caught by exception handlers.With the approach above, no exceptions are non-fatal. There is no "catch a signal and turn that into an exception" of any sort. -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Apr 26, 2006, at 11:02 PM, Chris Lattner wrote:>> By reordering two instructions that could throw exceptions. > > One of us is confused. The approach above never has instructions > that throw exceptions.I think we're talking about different cases. What you say is true about Tom's first approach (explicit comparisons before each potentially trapping instruction). I was talking about the second approach (taking a signal and converting that to an exception). That could be broken by reordering two such instructions. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/