<div dir="ltr">So, I'm really fine with experiments going on in tree here, I just wanted to know what the plan was (which Matt's email pretty much clarified) and make sure that there wasn't going to be increased confusion (which a comment such as Tobias mentions would do).<div>
<br></div><div>I don't think any of what has been discussed merits things being out-of-tree.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 8, 2014 at 12:25 PM, Matt Arsenault <span dir="ltr"><<a href="mailto:Matthew.Arsenault@amd.com" target="_blank">Matthew.Arsenault@amd.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 07/08/2014 12:14 PM, Tobias Grosser wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 08/07/2014 20:57, Matt Arsenault wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/07/2014 07:46 PM, Chandler Carruth wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, not really a comment on this specific patch, but how much more<br>
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<br>
generally incomplete and no one was happy about relying on dominance<br>
frontiers. Are these still significant concerns? What is the path<br>
forward? I was easily able to rewrite my code in terms of<br>
DominatorTrees instead of regions, and it in some ways became simpler,<br>
so I'm not really sold lots of effort going into enhancing the support<br>
of regions in the optimizer.<br>
<br>
Previously, it seemed like the region infrastructure in the optimizer<br>
served an important role of making it easy to experiment and explore<br>
optimizations in this space without imposing much maintenance burden<br>
for such experiments. But pushing the region support down into the<br>
machine layer seems much more to do with making this a core part of<br>
the expected optimization strategy, so that's why I'm asking now.<br>
<br>
</blockquote>
I asked Tobias about this last week, and his recommendation was that it<br>
would be useful to experiment by porting the existing infrastructure to<br>
the machine layer. He said he hasn't seen the theoretical O(N^2)<br>
behavior be a problem in practice, and it would be helpful for me to get<br>
started with the pass I want to write. I think the theoretical<br>
complexity and any other issues with RegionInfo are a problem for later<br>
</blockquote>
<br>
I generally agree with you and also believe enabling such kind of experiments are beneficial. However, Chandler is right in pointing out concerns. If we agree to commit such patches we need to point out the concerns clearly. Another option is to perform your experiments out-of-tree.  Is there a specific reason you would like to have these patches in-tree? (I have no strong opinion here, but would be interested to now)<br>

<br>
</blockquote></div></div>
Just the normal set of reasons. Doing things incrementally is always better, rather than showing up later with a large set of patches that do this, fix all the problems, and implement the pass for R600 I want to write. I've done this rather painful work already, and I'd rather have it in to avoid bitrot and having to redo anything major it if anybody touches RegionInfo before I finish, which might take a while.<br>

<br>
</blockquote></div><br></div>