[LLVMdev] Integer divide by zero

[Jeffrey Yasskin]

On Sun, Apr 7, 2013 at 7:24 PM, Cameron McInally
<cameron.mcinally at nyu.edu> wrote:
> Hey Jeffrey,
>
> Thanks for the suggestion. A few comments...
>
> On Sun, Apr 7, 2013 at 12:31 PM, Jeffrey Yasskin <jyasskin at googlers.com>
> wrote:
> ...
>>
>> 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.)
>
>
> This would work well for the constant expression division case, since the
> division by zero expression would be folded away leaving only a call to
> trap. The performance penalty for using -fsanitize on other non-constant
> division expressions is still unclear to me; and concerning.

If the performance penalty is unclear to you, that means you haven't
measured it. Until you measure, you have absolutely no business
complaining about a potential performance problem. Measure, and then
come back with numbers.

> Although, I've been contemplating x86-64's behaviour for this case when
> floating point traps are disabled. Ideally, the compiler should preserve
> that behaviour, which might make this software implementation messy.
> Especially if different processors have different implementations. The
> simplest solution... let the hardware behave as it should.

To be clear, you're asking to turn off a set of optimizations. That
is, you're asking to make code in general run slower, so that you can
get a particular behavior on some CPUs in unusual cases.

>> 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;".
>
>
> I believe that the constant folder would remove the constant division by
> zero and conditional before the backend could have its say. We would be left
> with only the jump to the error handler. That may complicate things.

If the compiler can prove x==0, then yes, you'd be left with just a
jump to the error handler. That's more efficient than handling a
hardware trap, so it's what you ought to want. In cases of
non-constant division by zero, the branch wouldn't usually get
removed, and the backend would get a chance to optimize it.