<div dir="ltr">On Saturday, April 6, 2013, Jeff Bezanson  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Presumably the optimizer benefits from taking advantage of the<br>
undefined behavior, but to get a consistent result you need to check<br>
for both zero and this case, which is an awful lot of checks. Yes they<br>
will branch predict well, but this still can't be good, for code size<br>
if nothing else. How much performance can you really get by constant<br>
folding -9223372036854775808/-1 to an unspecified value?<br>
</blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>-Joe</div>
</div>