[llvm-commits] [PATCH] Add RegionPass framework

[Tobias Grosser]

On 10/20/2010 12:25 PM, Devang Patel wrote:
> On Oct 13, 2010, at 4:21 AM, Tobias Grosser wrote:
>
>> Hi,
>>
>> ether and I would like to add a RegionPass framework to LLVM. RegionPasses are like loop passes, except that they are working on Regions provided by the RegionInfo pass instead of Loops provided by the LoopInfo pass.
>>
>> The RegionPass framework was tested intensively in the Polly[1] project, where it is used since about March.
>>
>> The patch contains all documentation as well as a very simple pass framework which works like the LoopPasses. We do not propose the functions needed to add/remove regions on the fly to keep the framework
>> as simple as possible.
>>
>> Thanks for your review
>> Tobi
>>
>> [1] http://wiki.llvm.org/Polyhedral_optimization_framework
>> <0001-Add-RegionPass-framework.patch>_______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>> diff --git a/include/llvm/Pass.h b/include/llvm/Pass.h
>> index f4c6eed..ed0fb39 100644
>> --- a/include/llvm/Pass.h
>> +++ b/include/llvm/Pass.h
>> @@ -57,6 +57,7 @@ enum PassManagerType {
>>     PMT_CallGraphPassManager,  ///<  CGPassManager
>>     PMT_FunctionPassManager,   ///<  FPPassManager
>>     PMT_LoopPassManager,       ///<  LPPassManager
>> +  PMT_RegionPassManager,     ///<  RGPassManager
>>     PMT_BasicBlockPassManager, ///<  BBPassManager
>>     PMT_Last
>>   };
>
>
>> +// Check if this pass is suitable for the current RGPassManager, if
>> +// available. This pass P is not suitable for a RGPassManager if P
>> +// is not preserving higher level analysis info used by other
>> +// RGPassManager passes. In such case, pop RGPassManager from the
>> +// stack. This will force assignPassManager() to create new
>> +// LPPassManger as expected.
>> +void RegionPass::preparePassManager(PMStack&PMS) {
>> +
>> +  // Find RGPassManager
>> +  while (!PMS.empty()&&
>> +         PMS.top()->getPassManagerType()>  PMT_RegionPassManager)
>> +    PMS.pop();
>> +
>
>
> This means, if you have two region passes RGP1&  RGP2 and one loop pass LP1 in RGP1, LP1, RGP2 then LP1 will terminate RGPAssManager instance created for RGP1. In other words, you'll get following execution sequence
>
> run RGP1 on region1
> run RGP1 on region2
> run LP1 on Loop 1 in region 1
> run LP1 on Loop 2 in region 1
> run LP1 on Loop 3 in region 2
> run RGP2 on region 1
> run RGP2 on region 2
>
> If this is what you expect then this is fine. However this won't work, if you expect following pass execution sequence.
>
> run RGP1 on region1
> run LP1 on Loop 1 in region 1
> run LP1 on Loop 2 in region 1
> run RGP2 on region 1
> run RGP1 on region2
> run LP1 on Loop 3 in region 2
> run RGP2 on region 2
>
> Just a thought, may this doesn't matter.

Hi,

you are right. At the moment the first sequence is executed, because 
there is no nesting defined between loops or regions, like it is for
function > loop > basicblock.

So loops and regions are on the same level as

function > region > basicblock

holds.

However comparing region and loop does not give any nesting.

At the moment this is fine as we do either use loop or region passes for 
our work in Polly. If future users of the region passes need a different 
behavior I am open for discussions.

Cheers

Tobi