llvm dev - May 2009 - [LLVMdev] 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,
-- 
Nick Johnson

On Apr 30, 2009, at 5:28 PM, Nick Johnson wrote:
> 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