[LLVMdev] Make LoopBase inherit from "RegionBase"?

[Jan Sjodin]

> I think this should be implemented as a RegionFilter, that checks if a

> region contains a loop, and that can be asked for further information.
> In general I do not think this kind of analysis belongs to a region, but
> as you proposed some kind of filter could be applied. In the short term
> the passes who need this information could get it on their own.
> 
>> and a long term consideration about "region pass":
>> 
>> if we want to integrate region analysis and optimization framework into
>> llvm,  i think we can use an approach that similar to loop analysis and
>> optimization: write a class "regionpass" inherit from "pass", and the
>> corresponding pass manger "RegionPassManager". (a kind of function pass)
>> if we follow this approach, we need to push the region pass manager into
>> the llvm pass manager stack.
>> the first question of this approach is, whats the relationship between
>> "loop pass manager" and "region pass manager"?
>> 
>> way 1: make region pass manager below loop pass manager in the stack
>> 
>> pass manager stack:
>> 
>> bb pass manager <---top
>> loop pass manager
>> region pass manager
>> function pass manager
>> ... <---bottom
>> 
>> in this way the region hierarchy need to be reconstruct when a loop
>> transform change it.
>> 
>> way 2: make region pass manager above loop pass manager in the stack
>> 
>> pass manager stack:
>> 
>> bb pass manager <---top
>> region pass manager
>> loop pass manager
>> function pass manager
>>     ... <---bottom
>> 
>> in this way the loop hierarchy need to be reconstruct when a region pass
>> change it.
>> 
>> now we need to choose a way to minimize the loop reconstruction or
>> region reconstruction. i think that the chance that a region transform
>> affect the loop structure is smaller, so maybe way 2 is better.
> This would need some thoughts. Ideal I think we would not order them, but if
> a region changed, just reconstruct the loops that are in this region and
> if a
> loop changed just reconstruct the regions in this loop.

Imo, a loop is simply a special kind of region, so a "filter" is perhaps the way to
go if you are interested in loops. Regions containing loops will have to be inspected
using the PST. 

>> at last, i have some idea about finding a interesting region: (maybe
>> make the region analysis too complex)
>> 
>> we can introduce some thing like "region filter" that determine the
>> property of a region, the region filter will like a "pass", which can
>> run on an instruction at a time, a basic block at a time, or even a sub
>> region at a time, then we can write a "filter manager" like "pass
>> manager " to stream the filtering process, so that we can promote the
>> the performance of the region finding process.
> Yes, I like this idea.
> So the basic design would be that we have some passes like:
> Maximal Region regarding an Analysis/Filter
> Minimal Region regarding an Analysis/Filter
> All Regions regarding an Analysis/Filter
> So a pass can ask the regionpass manager for a specific kind of regions.
> It is than just invoked for regions, that fulfill this requirement.

If you want to be able to manipulate specific regions you can have a
generic region class, and then sub classes for loop, if, unstructured etc. 
That way it is easy to ask for the body of a loop or the true or false regions
of an if-region. It will also allow you to have different kinds of loops for/do-while,
but still treat them in a uniform way in some cases. 

- Jan