<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 14, 2017 at 8:57 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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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="m_8299195538218387054gmail-">2017-03-13 20:43 GMT+01:00 Daniel Berlin via llvm-commits<br>
<<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>>:<br>
</span><span class="m_8299195538218387054gmail-">> 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></span><div>The linear time IDF calculation relies on the level numbering, which in turn, relies on the parent property.</div><span class=""><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></span><div>Yes, as does mine.</div><span class=""><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></span><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></div></div></blockquote><div><br></div><div>and note, it actually doesn't matter what the exact representation  you choose as an alternate:</div><div>Any representation where it does not connect a cycle member of b directly to the virtual exit edge has the same issue - it will break the parent property of the tree.</div></div></div></div>