[llvm] r206732 - Implement builtins for safe division: safe.sdiv.iN, safe.udiv.iN, safe.srem.iN,

[Eric Christopher]

Hi Andrew,

Replying in both places because this mail is a pretty good summary of
issues and so it's worth replying to... my apologies for continuing in
both places.

>
> The only language aspect under discussion is integer division. Every
> standardized language I'm aware of requires some form of check on integer
> division.
>
> Either the language is C-based, in which case we need to provide compiler
> options to achieve sanity:
> -fsanitize=integer-divide-by-zero:
> -fsanitize=signed-integer-overflow
>

I'm going to argue this one, this isn't part of language conformance,
unless you're optimizing your undefined behavior. :) I also haven't
seen patches to have clang emit this intrinsic anywhere.

> Or the language requires a check to determine whether to throw an exception.
>

Like Java? Something else?

> Or the language requires a check to determine whether the number needs to be
> promoted to a different representation.
>

Guessing JS here then? You could just actually state the kind of
behavior you're trying to work with rather than handwaving it. How
about show me some IR and how we'd like this to work? Michael started
that, but I haven't seen something with a front end language and how
we'd like to map such a thing onto IR.

> Of course, these can all be implemented with explicit checks in the IR. And
> at IR level, this is exactly the same situation as checking overflow on
> add/sub/mul. I have argued in the past just as you are now that there is
> already another way to represent the check. However, LLVM developers are now
> very heavily using the llvm.arith.with.overflow intrinsics and making the
> optimizer aware of them, I think we should be consistent. Anyway,
> implementing explicit checks in the IR (before CodeGenPrepare) tends to make
> the target independent IR heavily biased toward a particular architecture.
>

This is true, and we emit the IR with that instruction in the front
end so that we can do that reasonably effectively. I don't necessarily
know that the semantics of the divide instruction are as clear cut as
the overflow on add. Why is this the correct set of things that we
should be checking? INT_MIN / -1 (or %) is definitely undefined
behavior in C11/C++11 and could trap on various processors, but is
apparently defined to ... something on ARM64?

-eric