[PATCH] Templatify RegionInfo

Tobias Grosser tobias at grosser.es
Tue Jul 8 12:14:11 PDT 2014

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)


More information about the llvm-commits mailing list