[PATCH] Templatify RegionInfo

[Chandler Carruth]

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).

I don't think any of what has been discussed merits things being
out-of-tree.


On Tue, Jul 8, 2014 at 12:25 PM, Matt Arsenault <Matthew.Arsenault at amd.com>
wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140708/2018606a/attachment.html>