<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 8, 2014 at 11:19 AM, Tobias Grosser <span dir="ltr"><<a href="mailto:tobias@grosser.es" target="_blank">tobias@grosser.es</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 08/07/2014 19:24, Nadav Rotem wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Jul 7, 2014, at 7:46 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br>
<br>
So, not really a comment on this specific patch, but how much more effort do we want to push into the region support in LLVM?<br>
<br>
Last time I tried to use the region infrastructure I found it was generally incomplete and no one was happy about relying on dominance frontiers. Are these still significant concerns? What is the path forward? I was easily able to rewrite my code in terms of DominatorTrees instead of regions, and it in some ways became simpler, so I'm not really sold lots of effort going into enhancing the support of regions in the optimizer.<br>

</blockquote>
<br>
Dominance frontier is one way to compute Region info but the problem is that DF can grow quadratically.  There is a linear algorithm that is based on the Roman Chariots problem[1].<br>
<br>
[1] - <a href="http://dl.acm.org/citation.cfm?id=256217" target="_blank">http://dl.acm.org/citation.<u></u>cfm?id=256217</a><br>
</blockquote>
<br></div>
Nadav is right. There is different work in this area. There is e.g. the classical paper:<br>
<br>
"The program structure tree: Computing control regions in linear time"<br></blockquote><div><br></div><div>Sure, but that isn't actually my memory of the problem with dominance frontiers. The other problem we had was updating them so many times when they changed. Updating the domtree incrementally ended up being quite simple and it isn't clear that the same would be true for dominance frontiers or regions themselves.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To my understanding most algorithms only find what I call simple regions, which are regions that do have a single exit edge. Regions<br>
that have multiple exit edges, but which can be merged into a single one are often ignored.</blockquote></div><br>That is the other problem -- it would be a really radical change for LLVM to move to SESE functions, much less aggressively forming SESE CFG structures. So I don't know how useful these end up being.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Again, I'm very happy to have region info kicking around to make it easy to experiment and research the effects of new optimizations, but it semes strange to move it to hack on the machine level unless we have a concrete plan for more widespread usage without some of these challenges.</div>
</div>