[LLVMdev] Circular dependencies

[Reid Spencer]

Okay, its not that simple. 

Several files in Transforms/Utils depend on things in lib/Analysis. A
quick grep shows: 

BreakCriticalEdges.cpp:#include "llvm/Analysis/Dominators.h"
BreakCriticalEdges.cpp:#include "llvm/Analysis/LoopInfo.h"
CloneTrace.cpp:#include "llvm/Analysis/Trace.h"
CodeExtractor.cpp:#include "llvm/Analysis/Dominators.h"
CodeExtractor.cpp:#include "llvm/Analysis/LoopInfo.h"
CodeExtractor.cpp:#include "llvm/Analysis/Verifier.h"
InlineFunction.cpp:#include "llvm/Analysis/CallGraph.h"
Local.cpp:#include "llvm/Analysis/ConstantFolding.h"
PromoteMemoryToRegister.cpp:#include "llvm/Analysis/Dominators.h"
PromoteMemoryToRegister.cpp:#include "llvm/Analysis/AliasSetTracker.h"

Am I right in assuming that the goal here is to get libTransformUtils to
depend on nothing in libTransforms or libAnalysis? If so, its going to
take some significant code rearrangement.

Perhaps a lib/Analysis/Utils is in order?

Please advise.

Reid.

On Wed, 2006-03-22 at 08:13 -0800, Reid Spencer wrote:
> Okay, the problem with this cycle is LoopSimplify. It is using
> AliasAnalysis which is where that _ZN4llvm11BasicAAStubEv symbol is
> coming from.  It seems to me that LoopSimplify.cpp is in the wrong
> place.  This file defines the LoopSimplify FunctionPass which doesn't
> seem to me to be a "transform util". I thought the purpose of
> "Transforms/Util" was to provide utilities that are common amongst
> transforms. But, LoopSimplyf *is* a transform. So, I think the solution
> is to move LoopSimplify.cpp out of Transforms/Utils to somewhere else,
> say just "Transforms. By doing this, we probably eliminate the cycle.
> I'm going to validate that shortly.
> 
> Reid.
> 
> On Wed, 2006-03-22 at 09:26 -0500, Eric Kidd wrote:
> > On Mar 21, 2006, at 11:23 PM, Chris Lattner wrote:
> > >>>    LLVMCodeGen.o LLVMSelectionDAG.o libLLVMAnalysis.a  
> > >>> libLLVMTarget.a
> > >>>    libLLVMTransformUtils.a libLLVMipa.a
> > >
> > > CodeGen should depend on Target, but not the other way around.
> > > LLVMIPA should depend on LLVMAnalysis, but certainly nothing in the  
> > > list should depend on LLVMIPA.  If you knew what was pulling in IPA  
> > > that would probably be an easy tie to sever.
> > >
> > > Ideally, none of the above should depend on libLLVMTransformUtils.
> > 
> > Yeah, I'm definitely having headaches with LLVMTransformUtils, which  
> > needs to appear before  LLVMAnalysis and lLLVMTarget.
> > 
> >    -lLLVMTransformUtils -lLLVMAnalysis -lLLVMTarget
> > 
> > If I don't do this, I get link errors on:
> > 
> >    __ZN4llvm11BasicAAStubEv
> > 
> > I think, for now, the only portable workaround is for me to link all  
> > the *.a libraries in that loop twice, and hope we can clean up the  
> > dependencies later.
> > 
> > There's several places where llvm-config could be simplified quite a  
> > bit if we broke the unnecessary dependencies and merged the remaining  
> > loops into single *.a files. In some sense, parts of llvm-config are  
> > re-inventing the system linker. Depending on your point of view, this  
> > might be a bad thing. :-)
> > 
> > Many thanks to everyone who's helped sort this out!
> > 
> > Cheers,
> > Eric
> > 
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060322/e9d08889/attachment.sig>