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/
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
On Wed, 8 Nov 2006, Vikram Adve wrote:> ... 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.I think that the design will handle this. This isn't a matter of changing order of iteration. This is a matter of making sure that the new loops that are created get revisited. This is exactly what the worklist is design for. In any case, Devang has plenty of things to do to the current pass mgr and the current loop optimizations before we start worrying about new optzns. When that happens we'll have experience from moving the extant loop optimizers over to guide the right design. -Chris -- http://nondot.org/sabre/ http://llvm.org/