DominatorTrees, DominanceFrontiers, interfaces and cloning

Hello,

I have a transform that, given a function F, will produce a new
function G such that the basic blocks of G are (copies of) a subset of
the basic blocks of F, and such that control flow is connected as you
would expect. Given DominatorTree and DominanceFrontier of F, I would
also like to efficiently compute DominatorTrees and DominanceFrontiers
of G. I understand how to do this mathematically, but I'm having some
problems with the llvm codebase.

I have two questions:

(1) Is there any way to clone a DominatorTree or DominanceFrontier
object, so that I can modify the cloned copy? It looks like Pass
makes the copy constructor private...

(2) Is there any reason why functions (such as PromoteMemToReg) accept
parameters of types DominatorTree and DominanceFrontier instead of
types DominatorTreeBase and DominanceFrontierBase? It seems to me
that they should accept the abstract interface instead of the
implementation (and avoid the extra baggage of a pass).

Having said that, I'm willing to hack llvm and submit a patch; I just
wanted to see if its been done already...

Thank you,

Hello,

I have a transform that, given a function F, will produce a new
function G such that the basic blocks of G are (copies of) a subset of
the basic blocks of F, and such that control flow is connected as you
would expect. Given DominatorTree and DominanceFrontier of F, I would
also like to efficiently compute DominatorTrees and DominanceFrontiers
of G. I understand how to do this mathematically, but I'm having some
problems with the llvm codebase.

I have two questions:

(1) Is there any way to clone a DominatorTree or DominanceFrontier
object, so that I can modify the cloned copy? It looks like Pass
makes the copy constructor private...

The passes aren't designed to be used like this, but you could extend them if you want.

(2) Is there any reason why functions (such as PromoteMemToReg) accept
parameters of types DominatorTree and DominanceFrontier instead of
types DominatorTreeBase and DominanceFrontierBase? It seems to me
that they should accept the abstract interface instead of the
implementation (and avoid the extra baggage of a pass).

DomintatorTree (and friends) isn't designed to be an abstract interface. There is supposed to be exactly two subclasses of DominatorTreeBase: one for forward and one for reverse dominators. PromoteMemToReg doesn't take the base class, because it doesn't make sense for it to work on reverse dominators.

-Chris