On Tue, 7 Nov 2006, Vikram Adve wrote:> 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. 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.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. For example, function passes give up control over which order functions are processed in. This allows pipelining of a function through multiple function passes before the next function is processed. If each functionpass could define its own iteration order, this wouldn't work. Note that no generality is lost here: passes that don't fit the FunctionPass mold can be made into ModulePasses. The LoopPassManager is the same thing. The idea is that the LPM provides structured iteration among loop pass classes. I believe that most loop transformations will fit into the framework, and will thus enjoy the benefits of it. Those that don't can alway be FunctionPasses. -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Nov 7, 2006, at 2:02 PM, Chris Lattner wrote:> On Tue, 7 Nov 2006, Vikram Adve wrote: >> 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. 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. > > 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.> For example, function passes give up control over > which order functions are processed in. This allows pipelining of > a function through multiple function passes before the next > function is > processed. If each functionpass could define its own iteration order, > this wouldn't work. Note that no generality is lost here: passes that > don't fit the FunctionPass mold can be made into ModulePasses. > > The LoopPassManager is the same thing. The idea is that the LPM > provides > structured iteration among loop pass classes. I believe that most > loop > transformations will fit into the framework, and will thus enjoy the > benefits of it. Those that don't can alway be FunctionPasses.Yes, I agree -- you can't and shouldn't try to make LPM handle all possible cases. But if you can make the LoopPassManager more flexible and simpler at the same time, that seems worthwhile. --Vikram
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. How could it allow individual passes to control order of loop visitation? -Chris -- http://nondot.org/sabre/ http://llvm.org/