> <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">The only case this could regress is a potentially trapping operation that doesn't actually trap for reasons that are invisible to the optimizer.</span><div>
<font color="#222222" face="arial, sans-serif"><br></font></div><div><font color="#222222" face="arial, sans-serif">Like a divide operation where the divisor never happens to be zero? or am I misunderstanding the patch?</font></div>
<div><font color="#222222" face="arial, sans-serif"><br></font></div><div><font color="#222222" face="arial, sans-serif">My understanding is that now we will not hoist divides out of induction variable expressions where before we did, because divides can trap. Most divides in user code don't trap, so I don't see how you can conclude that the optimization is not firing on user code.</font></div>
<div><font color="#222222" face="arial, sans-serif"><br></font></div><div><font color="#222222" face="arial, sans-serif">That said, I agree let's fix the crash with the trivial fix proposed and deal with the performance impact later.<br>
</font><br><div class="gmail_quote">On 4 June 2013 16:41, Rafael Ávila De Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><div>We are more likely to fix a crash. So I don't think it is firing. The only case this could regress is a potentially trapping operation that doesn't actually trap for reasons that are invisible to the optimizer.</div>
<div><br></div><div>Adding the extra control flow to guard it is not clear to be a win. We should probably fix the miscompilation first. If we do have a perf regression somewhere, it can be addressed in a subsequent patch.<br>
<br>Sent from my iPhone</div><div><div class="h5"><div><br>On 2013-06-04, at 11:22, James Molloy <<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a>> wrote:<br><br></div><blockquote type="cite">
<div>Hi Rafael,<div><br></div><div>I don't know. Do we know this broken optimization doesn't kick in in the test suite? If it does, we'd regress on performance if we took the conservative way out.</div><div><br>
</div>
<div>Just my 2c.</div><div><br></div><div>Cheers,</div><div><br></div><div>James<br><br><div class="gmail_quote">On 4 June 2013 15:40, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 4 June 2013 09:49, James Molloy <<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a>> wrote:<br>


> Hi David,<br>
><br>
> Might a more performant solution not be to wrap any hoisted instructions<br>
> that are not safe to expand in a conditional that tests if the loop will be<br>
> entered at least once?<br>
<br>
</div>Is that really worth it? Given that this bug went undetected for years<br>
(it was already broken in r122610), I don't think it would kick often<br>
enough to justify it.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>
</div></blockquote></div></div></div></blockquote></div><br></div>