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.
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
I have not yet spent enough time to think about unimodular transformation framework implementation.