[LLVMdev] Integer divide by zero

[Jeff Bezanson]

I'm also not fully happy with LLVM's behavior here. There is another
undefined case too, which is the minimum integer divided by -1. In
Julia I can get "random" answers by doing:

julia> sdiv_int(-9223372036854775808, -1)
87106304

julia> sdiv_int(-9223372036854775808, -1)
87108096

In other contexts where the arguments are not constant, this typically
gives an FPE trap.
More than insisting on a particular behavior, I'd like it to be
consistent. I know the result is undefined, so LLVM's behavior here is
valid, but I find that to be an overly lawyerly interpretation.
Presumably the optimizer benefits from taking advantage of the
undefined behavior, but to get a consistent result you need to check
for both zero and this case, which is an awful lot of checks. Yes they
will branch predict well, but this still can't be good, for code size
if nothing else. How much performance can you really get by constant
folding -9223372036854775808/-1 to an unspecified value?

On Sat, Apr 6, 2013 at 1:18 AM, Owen Anderson <resistor at mac.com> wrote:
>
> On Apr 5, 2013, at 8:02 PM, Cameron McInally <cameron.mcinally at nyu.edu>
> wrote:
>
> I'm less concerned about "where" the trap happens as I am about "if" it
> happens. For example, a Fortran program with division-by-zero is, by the
> Standard, non-conforming. Pragmatically, not a Fortran program. Rather than
> wrong answers, I would like to see a hard error indicating that a program is
> non-conforming to the Standard.
>
>
> As I've pointed out, clang does provide such functionality as an opt-in
> feature through its -fsanitize options.  A hypothetical Fortran frontend
> could do the same, and even make it an opt-out feature if it chose.  I'm
> sorry if its implementation mechanism doesn't match exactly what you want it
> to be, but it's not like nobody else has thought about this problem.  They
> have, and they've designed and shipped a solution!
>
> Side note: even if the -fsanitize option introduces a branch around the
> division (which I haven't verified), it's quite unlikely to cause a
> significant performance regression.  The branch to the error block should be
> perfectly predicted on any CPU made in the last 25 years.
>
> --Owen
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>