[PATCH] Templatify RegionInfo

Matt Arsenault Matthew.Arsenault at amd.com
Tue Jul 8 12:25:27 PDT 2014

On 07/08/2014 12:14 PM, Tobias Grosser wrote:
> On 08/07/2014 20:57, Matt Arsenault wrote:
>> On 07/07/2014 07:46 PM, Chandler Carruth wrote:
>>> 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?
>>> 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.
>>> Previously, it seemed like the region infrastructure in the optimizer
>>> served an important role of making it easy to experiment and explore
>>> optimizations in this space without imposing much maintenance burden
>>> for such experiments. But pushing the region support down into the
>>> machine layer seems much more to do with making this a core part of
>>> the expected optimization strategy, so that's why I'm asking now.
>> I asked Tobias about this last week, and his recommendation was that it
>> would be useful to experiment by porting the existing infrastructure to
>> the machine layer. He said he hasn't seen the theoretical O(N^2)
>> behavior be a problem in practice, and it would be helpful for me to get
>> started with the pass I want to write. I think the theoretical
>> complexity and any other issues with RegionInfo are a problem for later
> 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)
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.

More information about the llvm-commits mailing list