<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 23, 2015 at 8:21 AM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon Feb 23 2015 at 7:38:37 AM Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>> This instruction doesn’t appear to be well formed. However, one could<br>
>> argue that it is – formally %2 def does dominate all %2 uses because both<br>
>> are located in an unreachable block, so every path to the use is passing<br>
>> through the def (because there are 0 paths like that).<br>
>><br>
>> That is likely the reason why –verify doesn’t complain about it.<br>
><br>
><br>
> Why is jump-threading creating this funky instruction?<br>
<br>
It is well formed. I agree with Hal: it might be a quality improvement<br>
to generate tidier IR from jump-threading, but GVN has to handle<br>
whatever input passes the verifier.<br></blockquote><div><br></div></span><div>Then, IMHO, we should start the long process of making forward-unreachable code not acceptable except inside a single pass (IE at the end of each pass, there should be no unreachable code).</div><div><br></div><div>There are a very very small number of passes that generate such code, and it's not that difficult to fix them to make them not do that.</div></blockquote></div><br>I will write up a longer reply soon, but I strongly disagree. I think this would be a really bad direction for LLVM to move in.</div></div>