divide by zero exception is not reliable

[JeffBezanson]

In LLVM semantics dividing by zero gives undefined behavior. Basically, in any case where it is able to evaluate the division at compile time you get a strange number answer instead of an exception:

julia> g()=begin
       local b=0
       div(1,b)
       end
Methods for generic function g
g()

julia> g()
-1081290856

[StefanKarpinski]

I guess the solution is to emit code that actually checks this and throws an exception at run time? We want to be careful not to deny ourselves the possibility of evaluating things at compile time, however. How about throwing an exception at compile time? I'm guessing LLVM doesn't support that so we'd have to have our own constant folding at compile time in order to throw a compile-time error, no?

[JeffBezanson]

I guess the bright side of this is that we know llvm's constant folding is working for us :)
I checked the vmkit source to see how they handle this for java, and they emit a check for zero with every integer divide. We probably have to do this too.

[StefanKarpinski]

If we could always catch these cases at compile time, then we wouldn't, right? This works as expected:

julia> f(a) = begin
         local b = 0
         div(a,b)
       end

julia> f(1)
error: integer divide by zero

Thus, if Julia's constant folding were as good as LLVM's and we caught the divide-by-zero at compile time, we wouldn't have to emit the check. It would be a little weird to generate a compile-time error for divide-by-zero. The alternative would be to detect the divide-by-zero at compile time and generate code that throws and exception when it's detected.

[JeffBezanson]

Yes, if you can statically prove division by zero then you emit code to throw an exception.

Even if we do have our own constant folding eventually, there's no way we can be sure it will handle everything the same as all of LLVM's optimizations. LLVM can do a lot of sophisticated rearrangement, and we can't risk giving a bogus answer like -1081290856. We should do the run-time check, and eventually see if it's possible to add a language-specific hook in llvm to intercept this case.

[JeffBezanson]

We can also measure the performance impact and possibly provide a nonzero_div_int intrinsic. If you want you can change int.j to use this --- a great thing about julia. Imagine modifying your JVM for something like this. Totally unrealistic.

[StefanKarpinski]

Nice. That's a lovely solution.

[JeffBezanson]

In a quick and dirty test the performance impact seemed to be negligible.