<div dir="ltr"><br><br><div class="gmail_quote">On Mon Feb 23 2015 at 7:38:37 AM Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com">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><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><div><br></div><div>On the other hand, having *all* passes required to handle pretty much garbage, as long as it's unreachable, has a pretty high cost.</div><div><br>GVN already spends a bunch of code and time trying to deal with the weirdness of unreachable code, as do a lot of other passes (For reference, 5-10% of GVN's testcases deal with making sure it doesn't crash on unreachable code, depending on how you count)<br></div><div><br></div><div>At least a few other passes i've dealt with in the past week also go out of their way, after dealing with normal code, to deal  with unreachable code just to avoid crashing themselves later. So we are wasting compile time and maintenance burden on it too.</div><div><br></div><div>Worse, they almost all have bugs in how they handle it (I found two this week while using a utility class for something).</div><div>Fixing them all to handle unreachable code "properly" (since there is no real proper thing to do in most cases except treat it as radioactive parts of the input that you shouldn't really touch, but still have to do something with,  since phi nodes may have unreachable predecessors, etc), IMHO, brings no appreciable benefit to the compiler, particularly <span style="font-size:13.1999998092651px">when the alternative is "make it illegal"</span><span style="font-size:13.1999998092651px">.</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The GVN crashes reduces to just running GVN in<br>
<br>
define i8 @foo(i8* %x) {<br>
bb0:<br>
  br label %bb2<br>
bb1:<br>
  %tmp1 = getelementptr inbounds i8* %tmp1, i64 1<br>
  br i1 false, label %bb2, label %bb1<br>
bb2:<br>
  %tmp2 = phi i8* [ %tmp1, %bb1 ], [ %x, %bb0 ]<br>
  %tmp3 = load i8* %tmp2, align 1<br>
  ret i8 %tmp3<br>
}<br>
<br>
Cheers,<br>
Rafael<br>
<br>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
</blockquote></div></div>