[PATCH] Templatify RegionInfo

[Tobias Grosser]

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.

>> To my understanding most algorithms only find what I call simple regions,
>> which are regions that do have a single exit edge. Regions
>> that have multiple exit edges, but which can be merged into a single one
>> are often ignored.
>
>
> That is the other problem -- it would be a really radical change for LLVM
> to move to SESE functions, much less aggressively forming SESE CFG
> structures. So I don't know how useful these end up being.

I don't get your point here. Are you suggesting the use of RegionInfo
should in some way replace existing strategies. I think this is
definitely the wrong way and I tried to clarify above that as long as
dominance based algorithms can be used, they should be used.

> Again, I'm very happy to have region info kicking around to make it easy to
> experiment and research the effects of new optimizations, but it semes
> strange to move it to hack on the machine level unless we have a concrete
> plan for more widespread usage without some of these challenges.

I agree here as well. It have certain doubts that every region based
algorithm can be expressed as a pure dominance based algorithm, but if
we identify cases where a region based approach seems better we should
clearly evaluate the cost/benefit.

Cheers,
Tobias