[LLVMdev] passmanagert and co improvement...

Saem Ghani saemghani at gmail.com
Thu Dec 22 15:32:45 PST 2005

Okay, I've been studying passmanagert and company for quite a while. 
Here are my conclusions.

It's actually not nearly as bad as I thought.

I'll outline the problem as I see it.

We want to be able to manage the way passes traverse things, in
particular a module's worth of functions.  As was in your example, we
want inliner and mem2reg calls interleaved, as we traverse functions
in callgraphscc order.  More generally, we want the ability to specify
traversals.  And specify passes that should use these traversals.

Currently, when you tell a function pass to go to work on a module, it
iterates through the module, as it pleases.  Now, this behaviour is
fine, but insufficient.

What we want is the ability to say, function pass, "run on traversal".
 As in, we'll provide an iterator and you work on that instead, a
pseudo module if you like.

Now, for actually specifying the traversals, we want to tell the
passmanager, A, B, and C are traversal strategies that we wish to use.
 This is a way of saying, not only run said passes, but use them for
traversal -- this has implications on life times.  Now, when we add a
plain old pass, we CAN say, add a pass with traversal strategy A or B
or C, or it'll default to run on module/whatever.

Passmanager, would require a couple of extra methods to expose this
new traversal management flexibility.

Traversal strategies, this is controvertial, here I want to have all
analysis we wish to use as traversal strategies to inherit from some
class, which provides an accessor to get a simple forward iterator, or
something in that vein.

Now, unless I'm not seeing the difficulty in this, it shouldn't be TOO
bad to implement the logic.  I could also be missing significant
design issues.

As for clean ups in passmanagert, I think the first thing might be
cutting down some of those insane multipage functions with private
helper functions, since they're one offs, we can easily inline them,
not to mention, they make things far more readable than large "code
barf".  Maybe, it's just me, but I can't stand big methods/functions. 
Overall, it's not all that bad.


More information about the llvm-dev mailing list