[LLVMdev] Integer divide by zero

[Jeffrey Yasskin]

On Sat, Apr 6, 2013 at 10:07 AM, Cameron McInally
<cameron.mcinally at nyu.edu> wrote:
> Hey Owen,
>
> Thanks for your reply. I definitely understand your perspective. Hopefully I
> can change it.  }:-)
>
> On Sat, Apr 6, 2013 at 1:18 AM, Owen Anderson <resistor at mac.com> wrote:
> ...
>>
>> 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.
>
> All kidding aside, an instruction is an instruction. We have the
> functionality in hardware for free; it would be a shame not to use it. I
> should also mention that for our team, performance is job #1. Extra
> instructions, however insignificant, don't go over well without solid
> justification.

If you can find a way to implement -fsanitize=undefined to use the FP
trap instead of a branch when checking floating division by 0, I
suspect such a patch would stand a good chance of being accepted.
(Although I'm not intimately familiar with the implementation, so
there could be some subtlety that would prevent it.) You might need to
do this in the processor-specific backend to avoid other
undefined-behavior-based optimizations—that is, recognize "if (x == 0)
goto err_handler; else y/x;" and replace it with
"register-pc-in-fp-handler-map(); turn-on-fp-traps(); y/x;".

Jeffrey