[LLVMdev] Circular dependencies
reid at x10sys.com
Wed Mar 22 08:22:59 PST 2006
Okay, its not that simple.
Several files in Transforms/Utils depend on things in lib/Analysis. A
quick grep shows:
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?
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.
> 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...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the llvm-dev