<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 14, 2017 at 6:31 AM, Michael Kruse <span dir="ltr"><<a href="mailto:llvm-commits@meinersbur.de" target="_blank">llvm-commits@meinersbur.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">2017-03-13 20:43 GMT+01:00 Daniel Berlin via llvm-commits<br>
<<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>>:<br>
</span><span class="gmail-">> As another analysis example, this will break the linear time reverse IDF<br>
> calculation. It already does (and adce tries to work around that now), but<br>
> it will so even more :)<br>
<br>
</span>How can that be?</blockquote><div><br></div><div>The linear time IDF calculation relies on the level numbering, which in turn, relies on the parent property.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> All Tobias' suggestion does it adding a phantom edge.<br></blockquote><div><br></div><div>Yes, as does mine.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The most number of edges it could add is the number of blocks. If IDF<br>
is linear, let's say in the number of edges, then this would just add<br>
a constant per additional edge, or something linear in the number of<br>
blocks.</blockquote><div><br></div><div>This is not the part that breaks.</div><div>As mentioned, you can see *it already* breaks and ADCE is already trying to work around it.</div><div><br></div><div>The part that breaks is that it assumes the level number is also representative of paths that can exist in the CFG when computing IDF.</div><div>That is, the proof of correctness of stopping after processing a given level relies on the paths in the CFG vs the paths in the dominator tree.</div><div>In Tobias's representation, this does not work, because he has broken the normal parent property of dominator trees.</div><div><br></div><div>Imagine the following CFG;</div><div><br></div><div> a</div><div> / \</div><div>b c</div><div> |</div><div> exit</div><div><br></div><div>where b is a self-loop.</div><div><br></div><div>The post-dom tree, in tobias's representation will be</div><div><br></div><div> virtual exit</div><div> |</div><div> exit</div><div> |</div><div> c</div><div> / \</div><div>b a</div><div><br></div><div>In mine, it will be:</div><div>virtual exit</div><div> | | \</div><div> | | exit</div><div> | | \ </div><div>a b c</div><div><br></div><div><br></div><div>One of the two normal invariants of the dominator/post-dominator tree is that if y is a descendant of x in the tree, there must exist a path from x to y.</div><div>This is in fact, one of the *only* two things that makes a thing a dominator tree, and is a necessary precondition. See <a href="https://arxiv.org/abs/1604.02711">https://arxiv.org/abs/1604.02711</a> for proof[1].</div><div><br></div><div>In Tobias's representation, b is a child of c, but no path from c to b exists, breaking that invariant. The IDF calculator will believe that once it has finished processing c, at level 1, that it must already also have calculated a correct answer b for at level 2.</div><div>This is wrong.</div><div>In my representation, because they are the same level, it will continue processing, as it should.</div><div><br></div><div><br></div><div>[1] </div><div>Since post-dom is not actually defined for reverse-unreachable blocks, the actual dom/post-dom tree invariant is that if y is reachable vertex, .... Hence the disagreement tobias and I have. In my view, the whole point of adding reverse-unreachable blocks to the post-dom tree is to give them the same invariants the existing blocks have. There's no point in having them in a post-dom tree if they don't meet the other invariants of the post-dom tree. It's useless. This is why literally every compiler attaches it to the exit block. </div><div><br></div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-HOEnZb"><font color="#888888"><br>
Michael<br>
</font></span></blockquote></div><br></div></div>