<div dir="ltr">Just saw that you "accepted" this in phab together with your "<span style="font-family:arial,sans-serif;font-size:13px">so I guess it's okay" comment ;)</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Submitted as </span><font face="arial, sans-serif">r209531.</font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 23, 2014 at 6:36 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.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="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Thu, May 22, 2014 at 6:42 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br>

</div><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Okay, I think I understand now. If the first dead statement is the first expression in a return statement, and then there's a temporary destructors block, and then the return statement, then we'd still want to treat that as part of the return statement. And that happens right now because we don't optimize out the case with no control flow.<br>


<br>
I'm worried, though, that this will catch something in a dead else block and go sailing off the end to look for a return statement,</blockquote><div><br></div></div><div>Btw, with the current implementation we will not sail off the end of else-blocks:</div>
<div class="">
<div><span style="font-family:arial,sans-serif;font-size:13px">+      if (Current->pred_size() > 1) {</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">+        // If there is more than one predecessor, we're dealing with incoming</span><br style="font-family:arial,sans-serif;font-size:13px">

<span style="font-family:arial,sans-serif;font-size:13px">+        // control flow - if the return statement is in that block, it might</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">+        // well be reachable via a different control flow, thus it's not dead.</span><br style="font-family:arial,sans-serif;font-size:13px">

<span style="font-family:arial,sans-serif;font-size:13px">+        return false;</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">       }</span><br>
</div>
<div><br></div></div><div>Let me know if you want me to change anything, or if you have an idea for a fundamentally different approach.</div><div class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

 build a parent map, and then not actually find anything (of course). It seems like a fair amount of extra work. Then again, we have already decided to emit a diagnostic at this point, so I guess it's okay.<br>
<br>
<a href="http://reviews.llvm.org/D3638" target="_blank">http://reviews.llvm.org/D3638</a><br>
<br>
<br>
</blockquote></div></div><br></div></div>
</blockquote></div><br></div>