<br><br><div class="gmail_quote">On Tue, Oct 11, 2011 at 10:00 AM, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204, 204, 204);border-left-width:1px;border-left-style:solid">




<div class="gmail_quote"><div><div></div><div>On 11 October 2011 02:11, Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr" target="_blank">baldrick@free.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204, 204, 204);border-left-width:1px;border-left-style:solid">






Hi David,<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204, 204, 204);border-left-width:1px;border-left-style:solid"><div>
It's really close, but not quite. Given the attached llvm assembly, the function<br>
call is correctly devirtualized (but the branch is left in). But if you comment<br></div>
out the first ret void (in the <a href="http://vtable.ne" target="_blank">vtable.ne</a> <<a href="http://vtable.ne" target="_blank">http://vtable.ne</a>> block) & comment in<div><br>
the unreachable instruction then the branch is removed by the simplifycfg pass &<br>
no interesting information about the condition is preserved for use by the GVN<br>
pass so the call is still indirect/virtual.<br>
</div></blockquote>
<br>
I thought there was a plan that a branch to a block containing only unreachable<br>
shouldn't be removed by the IR optimizers (instead codegen would remove it).  I<br>
even though Nick implemented this.  But apparently not...<br></blockquote><div><br></div></div></div><div>Implemented but never committed. It had a lot of undesirable side-effects in terms of preventing other optimizations from happening.</div>




<div> </div></div></blockquote><div> </div><div>Yeah, I can see how it could hinder other optimizations - though their presence hinders some optimizations (such as this one) too. It really limits the power of the unreachable instruction if all it does is cause the block to be removed up-front. </div>




<div> </div><div>A somewhat naive suggestion: would it make sense to run some optimizations before removing unreachable blocks & then again after they've been removed?<br><br>[& in addition: does this still seem like the right approach to the original bug or are there other options to consider?]<br>
<br>Thanks,</div><div>- David</div>


</div><br>