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/c78e4090/attachment.sig>
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>
On Wed, 22 Mar 2006, Reid Spencer wrote:> 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?I think it's ok for TransformUtils to depend on Analysis. Having xformations depend on analyses is ok, we just don't want the opposite. -Chris> 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 >-Chris -- http://nondot.org/sabre/ http://llvm.org/