[LLVMdev] Integer divide by zero

[dag at cray.com]

Jeffrey Yasskin <jyasskin at google.com> writes:

>> 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.

Oh come on.  He's expression concern, not saying it's a definite problem
or complaining.

>> 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.

No.  He's asking to turn off a particular optimization case for a
certain _known_ constant expression.  Furthermore, he's asking for an
option, not to blindly turn it off for everyone.

> 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.

Not necessarily.  See my example of using traps to aid debugging.  A
jump to a handler would disrupt machine state.  Perhaps not greatly but
it is an extra complication users don't expect.

                                -David