<div dir="ltr">Ohh, duh. Just did the math in my head. All makes sense now. Probably had the same thought process you were having when I initially thought it should be zero. <div><br></div><div>Thanks for the quick responses.</div><div>-Dilan</div><div><div class="gmail_quote"><div dir="ltr">On Tue, May 31, 2016 at 4:12 PM Tim Northover <<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 31 May 2016 at 16:02, Dilan Manatunga <<a href="mailto:manatunga@gmail.com" target="_blank">manatunga@gmail.com</a>> wrote:<br>
> Just to verify, a 16-bit divion of INT16_MIN  by -1 results in INT16_MIN<br>
> again?<br>
<br>
No, "sdiv i16 -32768, -1" is undefined behaviour. The version with an<br>
"sext" and "trunc" avoids the undefined behaviour and does return<br>
-32768.<br>
<br>
> If the issue only occurs in this case, why aren't there checks to see if we<br>
> can simplify sdiv in cases where we know that numerator is not INT16_MIN or<br>
> the denominator is not -1. For example, we could simplify divides involving<br>
> one operand constants. Is it because this case is most likely rare?<br>
<br>
It's probably just that no-one has bothered to implement it, I'd<br>
actually expect the code to be reasonably common from C compilation.<br>
Another factor is that RISC CPUs mostly won't care (they tend to only<br>
have natural width division anyway), so that removes a large swathe of<br>
people who might be interested.<br>
<br>
Cheers.<br>
<br>
Tim.<br>
</blockquote></div></div></div>