[LLVMdev] PassManager

[Vikram Adve]

On Nov 7, 2006, at 6:32 PM, Chris Lattner wrote:

> On Tue, 7 Nov 2006, Vikram Adve wrote:
>>> I think I see the issue here.  The point of the pass manager (in
>>> general)
>>> is for passes to *give up control* over iteration order in order for
>>> obtain something else.
>>
>>
>> Right, I understand that.  I think that works fine in most cases.
>> For loop passes, though, this approach is causing some of the
>> complexity issues you talked about in your notes.  You could avoid
>> them, and also make some loop passes, more natural to write if you
>> relaxed this policy and allow a transformation algorithm to choose
>> what subsets of loops to visit at a time.
>
> The idea is that the LPM (roughly) runs *all* the loop passes on an  
> inner
> loop, then runs them all on an outer loop.

Right, I understand that is the normal policy, but ...

>
> How could it allow individual passes to control order of loop  
> visitation?

... you would relax that policy for cases where the pass wants  
control over its order of visitation.  In fact , some passes (e.g.,  
loop tiling) may want to do two or more transforms on a set of loops  
at a time.  E.g., loop tiling needs to do strip-mining on a loop,  
then interchange one of the resulting loops with *some* outer loop  
(which one depends on the pattern of accesses in the code).  It would  
be nice for the LPM to have the flexibility to accommodate such  
passes better than just requiring them to always work at the  
outermost loop level.

Note that this is just one example.  All that is needed is an  
optional iterator method or callback method of some kind in the loop  
pass.  If unimplemented, it uses the default order.


>
> -Chris
>
> -- 
> http://nondot.org/sabre/
> http://llvm.org/
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev