Hi Vikram, On Nov 7, 2006, at 10:19 AM, Vikram Adve wrote:> Chris and Devang, > > Before you implement the LoopPassManager class, I'd like to discuss > this a little bit. I have a suggestion and a question; we can > discuss this now or later, as you wish: > > 1. The LoopPassManager might become much simpler if the more complex > loop passes are given control over how they iterate over the loops, > rather always rely on the manager to enumerate the loops in some > fixed order. Then the pass could be responsible for making sure that > it handles issues like loops that are deleted during the pass.LoopPassManager will manage the LoopInfo. It will maintain loop priority queue and expose APIs to add/remove loops that transformations can use.> For > example, some algorithms make internal decisions about which loops to > handle together and also what order to visit them. For example, the > LoopFusion class may need to inspect loop headers to decide which > subsets of loops to fuse and then fuse them as it goes.LoopPassManager will expose two virtual methods. 1) runOnLoop(Loop &L, LoopPassManger &LPM) Loop transformation can override to process this particular loop. 2) runOnFunctionBody(Function &F, Loop&L, LoopPassManager &LPM) LoopFusion and others can override this to to analyze and process multiple loops.> > I think you could do this just by adding an iterator method somewhere > that enumerates sets of loops (i.e,. returns a vector of Loop > objects). The bottom-up iterator could just be a default choice. > > 2. The question is how you plan to handle unimodular > transformations. I think it's a very nice abstraction and a number > of loop transforms should be implemented using that rather than more > ad hoc code, e.g., interchange, reversal, skewing. But that requires > implementing support for unimodular transforms before those passes > are implemented.I have not yet spent enough time to think about unimodular transformation framework implementation. - Devang
Devang, I read Chris's notes so I got all this information there already. My comments were in response to that. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Nov 7, 2006, at 12:34 PM, Devang Patel wrote:> Hi Vikram, > > On Nov 7, 2006, at 10:19 AM, Vikram Adve wrote: > >> Chris and Devang, >> >> Before you implement the LoopPassManager class, I'd like to discuss >> this a little bit. I have a suggestion and a question; we can >> discuss this now or later, as you wish: >> >> 1. The LoopPassManager might become much simpler if the more complex >> loop passes are given control over how they iterate over the loops, >> rather always rely on the manager to enumerate the loops in some >> fixed order. Then the pass could be responsible for making sure that >> it handles issues like loops that are deleted during the pass. > > LoopPassManager will manage the LoopInfo. It will maintain loop > priority queue and expose APIs to add/remove loops that > transformations can use. > > >> For >> example, some algorithms make internal decisions about which loops to >> handle together and also what order to visit them. For example, the >> LoopFusion class may need to inspect loop headers to decide which >> subsets of loops to fuse and then fuse them as it goes. > > LoopPassManager will expose two virtual methods. > > 1) runOnLoop(Loop &L, LoopPassManger &LPM) > > Loop transformation can override to process this particular > loop. > > 2) runOnFunctionBody(Function &F, Loop&L, LoopPassManager &LPM) > > LoopFusion and others can override this to to analyze and process > multiple loops. > >> >> I think you could do this just by adding an iterator method somewhere >> that enumerates sets of loops (i.e,. returns a vector of Loop >> objects). The bottom-up iterator could just be a default choice. >> >> 2. The question is how you plan to handle unimodular >> transformations. I think it's a very nice abstraction and a number >> of loop transforms should be implemented using that rather than more >> ad hoc code, e.g., interchange, reversal, skewing. But that requires >> implementing support for unimodular transforms before those passes >> are implemented. > > I have not yet spent enough time to think about unimodular > transformation framework implementation. > > - > Devang > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Nov 7, 2006, at 10:47 AM, Vikram Adve wrote:> Devang, > > I read Chris's notes so I got all this information there already. My > comments were in response to that.In that case I completely missed your question :) Do you suggest that complex loop passes iterates of all loops in the function by themselves (instead of LPM handing them instance of loop to process)? - Devang> --Vikram > http://www.cs.uiuc.edu/~vadve > http://llvm.cs.uiuc.edu/ > > > On Nov 7, 2006, at 12:34 PM, Devang Patel wrote: > >> Hi Vikram, >> >> On Nov 7, 2006, at 10:19 AM, Vikram Adve wrote: >> >>> Chris and Devang, >>> >>> Before you implement the LoopPassManager class, I'd like to discuss >>> this a little bit. I have a suggestion and a question; we can >>> discuss this now or later, as you wish: >>> >>> 1. The LoopPassManager might become much simpler if the more complex >>> loop passes are given control over how they iterate over the loops, >>> rather always rely on the manager to enumerate the loops in some >>> fixed order. Then the pass could be responsible for making sure >>> that >>> it handles issues like loops that are deleted during the pass. >> >> LoopPassManager will manage the LoopInfo. It will maintain loop >> priority queue and expose APIs to add/remove loops that >> transformations can use. >> >> >>> For >>> example, some algorithms make internal decisions about which loops >>> to >>> handle together and also what order to visit them. For example, the >>> LoopFusion class may need to inspect loop headers to decide which >>> subsets of loops to fuse and then fuse them as it goes. >> >> LoopPassManager will expose two virtual methods. >> >> 1) runOnLoop(Loop &L, LoopPassManger &LPM) >> >> Loop transformation can override to process this particular >> loop. >> >> 2) runOnFunctionBody(Function &F, Loop&L, LoopPassManager &LPM) >> >> LoopFusion and others can override this to to analyze and >> process >> multiple loops. >> >>> >>> I think you could do this just by adding an iterator method >>> somewhere >>> that enumerates sets of loops (i.e,. returns a vector of Loop >>> objects). The bottom-up iterator could just be a default choice. >>> >>> 2. The question is how you plan to handle unimodular >>> transformations. I think it's a very nice abstraction and a number >>> of loop transforms should be implemented using that rather than more >>> ad hoc code, e.g., interchange, reversal, skewing. But that >>> requires >>> implementing support for unimodular transforms before those passes >>> are implemented. >> >> I have not yet spent enough time to think about unimodular >> transformation framework implementation. >> >> - >> Devang >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Tue, 7 Nov 2006, Vikram Adve wrote:> I read Chris's notes so I got all this information there already. My > comments were in response to that.It's unclear what you're missing then: fusion can be easily handled by the framework. Unimodular transform support is orthogonal to the pass framework and could be built as a later step. Am I misunderstanding your question? -Chris> On Nov 7, 2006, at 12:34 PM, Devang Patel wrote: > >> Hi Vikram, >> >> On Nov 7, 2006, at 10:19 AM, Vikram Adve wrote: >> >>> Chris and Devang, >>> >>> Before you implement the LoopPassManager class, I'd like to discuss >>> this a little bit. I have a suggestion and a question; we can >>> discuss this now or later, as you wish: >>> >>> 1. The LoopPassManager might become much simpler if the more complex >>> loop passes are given control over how they iterate over the loops, >>> rather always rely on the manager to enumerate the loops in some >>> fixed order. Then the pass could be responsible for making sure that >>> it handles issues like loops that are deleted during the pass. >> >> LoopPassManager will manage the LoopInfo. It will maintain loop >> priority queue and expose APIs to add/remove loops that >> transformations can use. >> >> >>> For >>> example, some algorithms make internal decisions about which loops to >>> handle together and also what order to visit them. For example, the >>> LoopFusion class may need to inspect loop headers to decide which >>> subsets of loops to fuse and then fuse them as it goes. >> >> LoopPassManager will expose two virtual methods. >> >> 1) runOnLoop(Loop &L, LoopPassManger &LPM) >> >> Loop transformation can override to process this particular >> loop. >> >> 2) runOnFunctionBody(Function &F, Loop&L, LoopPassManager &LPM) >> >> LoopFusion and others can override this to to analyze and process >> multiple loops. >> >>> >>> I think you could do this just by adding an iterator method somewhere >>> that enumerates sets of loops (i.e,. returns a vector of Loop >>> objects). The bottom-up iterator could just be a default choice. >>> >>> 2. The question is how you plan to handle unimodular >>> transformations. I think it's a very nice abstraction and a number >>> of loop transforms should be implemented using that rather than more >>> ad hoc code, e.g., interchange, reversal, skewing. But that requires >>> implementing support for unimodular transforms before those passes >>> are implemented. >> >> I have not yet spent enough time to think about unimodular >> transformation framework implementation. >> >> - >> Devang >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-Chris -- http://nondot.org/sabre/ http://llvm.org/