[PATCH] Templatify RegionInfo
chandlerc at google.com
Tue Jul 8 11:39:46 PDT 2014
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>
>>> 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.
>>  - 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.
> 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits