[PATCH] Templatify RegionInfo

Tobias Grosser tobias at grosser.es
Tue Jul 8 16:00:14 PDT 2014

On 08/07/2014 20:59, Tobias Grosser wrote:
> On 08/07/2014 20:39, Chandler Carruth wrote:
>> On Tue, Jul 8, 2014 at 11:19 AM, Tobias Grosser <tobias at grosser.es>
>> wrote:
>>> On 08/07/2014 19:24, Nadav Rotem wrote:
>>>>   On Jul 7, 2014, at 7:46 PM, Chandler Carruth <chandlerc at google.com>
>>>>> 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.
>>>> 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].
>>>> [1] - http://dl.acm.org/citation.cfm?id=256217
>>> Nadav is right. There is different work in this area. There is e.g. the
>>> classical paper:
>>> "The program structure tree: Computing control regions in linear time"
>> 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.
> This is very true (and in my opinion even the bigger issue). We should
> add a warning to the RegionInfo pass. What about the following:
> WARNING: LLVM is generally very concerned about compile time, such that
>           the use of additional analysis passes in the default
>           optimization sequence is avoided as much as possible.
>           Specifically, if you do not need the RegionInfo, but dominance
>           information could be sufficient please base your work only on
>           the dominator tree. Most passes maintain it, such that using
>           it has often near zero cost. In contrast RegionInfo is by
>           default not available, is not maintained by existing
>           transformations and there is no intention to do so.

Committed in r212570.


More information about the llvm-commits mailing list