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

[Andrew Trick]

On Apr 23, 2014, at 1:50 PM, Eric Christopher <echristo at gmail.com> wrote:

> On Tue, Apr 22, 2014 at 6:45 PM, Andrew Trick <atrick at apple.com> wrote:
>> 
>> On Apr 22, 2014, at 8:19 AM, Eric Christopher <echristo at gmail.com> wrote:
>> 
>> One of Michael’s early implementations worked completely within the
>> SelectionDAG. We could share that patch if it’s interesting. The goal was to
>> mimic the rest of the llvm.arith.with.overflow intrinsics, including
>> lowering them through the same codegen mechanism.
>> 
>> 
>> Right. Those are needed for correct behavior. This is not so it
>> doesn't seem like a good analogy here.
>> 
>> 
>> I think the new division intrinsics are needed for correct behavior, as much
>> as the other overflow intrinsics are. The only difference I can see is that
>> architectures typically support reporting overflow on integer add/mul in the
>> form of flags. Whereas with division we need to emit some code to do the
>> checks.
>> 
> 
> Can you show some aspect of any standardized language that can't be
> handled otherwise?

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

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

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

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.

> Also, I've not seen the mail you were mentioning on llvm-dev?

Yeah. I believe Michael will be posting his proposal on the dev list later today. And the discussion can carry on there.

-Andy

> 
> -eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140423/d5f0a20c/attachment.html>