[LLVMdev] Integer divide by zero

[Chandler Carruth]

On Sun, Apr 7, 2013 at 9:28 PM, Cameron McInally
<cameron.mcinally at nyu.edu>wrote:

> More productive (IMO) is to emit explicit guards against the undefined
>> behavior in your language, much as -fsanitize does for undefined behavior
>> in C++. Then work to build a mode where a specific target can take
>> advantage of target specific trapping behaviors to emit these guards more
>> efficiently. This will allow LLVM's optimizers to continue to function in
>> the world they were designed for, and with a set of rules that we know how
>> to build efficient optimizers around, and your source programs can operate
>> in a world with checked behavior rather than undefined behavior. As a
>> useful side-effect, you can defer the target-specific optimizations until
>> you have benchmarks (internally is fine!) and can demonstrate the
>> performance problems (if any).
>>
>
> Regrettably, this implementation does not suit my needs.
>

I'm curious why you think so... I think it would very closely match your
needs:


> The constant folding would still occur
>

No? At least, I don't see why.

I don't know what your frontend is doing (but my impression is that it is
not Clang? If I'm wrong, let me know...) but the common idiom is to emit
nothing as a constant other than immediate values, and let LLVM's
optimizers figure it out. A consequence of this pattern combined with
inserting guards is that (at most) the optimizer will fold directly to the
trap. You should be able to control the exact structure in the FE though.

and I would like to produce the actual division, since the instruction is
> non-maskable on x86.
>

Yes, and this is the point I was driving at with the comments about a
target specific optimization. It is reasonable for the x86 backend to
recognize the pattern of testing for a zero divisor and trapping if it
occurs, and transform that into an unconditional divide relying on the
hardware trap instead. I think it is not unreasonable to have this strategy
result in one of two generated code patterns in the overwhelming majority
of cases:

1) An unconditional trap because the optimizer proved divide by zero
2) A direct divide instruction which relies on the x86 trapping behavior.

That said, it remains a fairly significant amount of work to arrive at this
place. Just trying to point out a reasonable approach to arriving there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130407/a17842d2/attachment.html>