A division intrinsic with defined behavior on all arguments would be
awesome! Thanks for considering this.
On Sat, Apr 6, 2013 at 11:27 AM, Joe Groff <arcata at gmail.com>
wrote:> On Saturday, April 6, 2013, Jeff Bezanson wrote:
>>
>>
>> Presumably the optimizer benefits from taking advantage of the
>> undefined behavior, but to get a consistent result you need to check
>> for both zero and this case, which is an awful lot of checks. Yes they
>> will branch predict well, but this still can't be good, for code
size
>> if nothing else. How much performance can you really get by constant
>> folding -9223372036854775808/-1 to an unspecified value?
>
>
> Constant folding undefined expressions is sort of silly, but I appreciate
> that it makes undefined behavior problems in frontends immediately apparent
> with trivial cases before they creep up on you in more complicated
optimized
> code. After all, even if the backend makes practical concessions to trivial
> cases, the underlying semantic problem is still there and will bite you
> eventually. For high-level languages like Julia that want to provide
> efficiency but also give defined behavior to all user-exposed cases, I
think
> adding an LLVM intrinsic to represent division that's defined to trap
on
> division by zero or overflow would be the best solution. Since the trap is
a
> side effect, it would stifle optimization of code that used the intrinsic,
> but the intrinsic could still be lowered to a single hardware instruction
> and avoid the branching and code bloat of manual checks on hardware where
> division by zero natively traps.
>
> -Joe