<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 10:41 AM, 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"><span class="">>> all the zero paths from entry to %a pass by %b.<br>
><br>
><br>
> That is a graph-wise definition, sure.<br>
> So, this is an interesting definition, and maybe this is part of the source<br>
> of the problem.<br>
><br>
> For SSA, at least GCC requires that both "definition block dominates use<br>
> block" (which would be true here), *and*<br>
> that "definition appears before use in block" (IE definition locally<br>
> dominates use).<br>
><br>
> IE it has to pass both DT->dominates(block(%b), block(%a)) and<br>
> DT->dominates(%b, %a).<br>
><br>
> LLVM special cases "not reachable from entry", and says that no matter what,<br>
> #2 is true if %a is unreachable.<br>
><br>
> The code is, IMHO, not even self-consistent<br>
><br>
><br>
>    // Any unreachable use is dominated, even if Def == User.<br>
>    if (!isReachableFromEntry(UseBB))<br>
>      return true;<br>
><br>
>    // Unreachable definitions don't dominate anything.<br>
>    if (!isReachableFromEntry(DefBB))<br>
>      return false;<br>
><br>
><br>
><br>
> Riddle me this: If unreachable definitions dominate nothing, how are<br>
> unreachable uses always dominated by their unreachable defs?<br>
<br>
</span>I think the comment is just just missing an "otherwise" at the start.<br></blockquote><div><br></div><div>It also doesn't explain "why" it decided this is the case :)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If we were to define dominance rules as you suggest, we would still accept<br>
<br>
define void @f() {<br>
bb0:<br>
  ret void<br>
bb1:<br>
<span class="">  %a = getelementptr inbounds i8* %b, i64 1<br>
</span>  ret void<br>
bb2:<br>
<span class="">  %b = getelementptr inbounds i8* %a, i64 1<br>
</span>  ret void<br>
}<br>
<br>
Since bb1 dominates bb2 and bb2 dominates bb1, no?<br></blockquote><div><br></div><div>Yes, if we consider unreachable blocks to dominate everything (IE the dom-tree is not acyclic), it is just as bad of a result.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It looks like a case where we would just be getting a bigger rug to<br>
swipe dirt under. </blockquote><div><br></div><div>Yes, you are likely right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think the definition we have is sound. It creates<br>
odd cases, but, as you point out, it looks like we can just require<br>
passes to cleanup such cases by deleting forward unreachable code.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>