On Tue, 25 Jul 2006, Reid Spencer wrote:> Now that we have a "-why" option to the GenLibDeps.pl utility
(which is
> used by llvm-config to deduce library dependencies), a review of the
> output has led to a few dubious library dependencies. Here they are:
Thanks for the great info and the llvm-config extensions Reid.
I will try to start snipping some of these tomorrow.
-Chris
> All of the following dependencies are singletons (the dependent library
> depends on only a single symbol from the dependency library):
>
> libLLVMCodeGen.a: libLLVMAnalysis.a(llvm::LoopInfoLinkVar)
> libLLVMCodeGen.a: libLLVMipo.a(PATypeHolder::get() const)
> libLLVMArchive.a: libLLVMCore.a(Module::~Module)
> libLLVMAsmParser.a:
> libLLVMSupport.a(IncludeFile::IncludeFile(void*)
> libLLVMCBackend.a: libLLVMAnalysis.a(llvm::LoopInfoLinkVar)
> libLLVMInstrumentation.a:
> libLLVMScalarOpts.a(llvm::DemoteRegisterToMemoryID)
> LLVMIA64.o: libLLVMCodeGen.a(vtable for
> llvm::DefaultIntrinsicLowering)
> libLLVMTarget.a: libLLVMCodeGen.a(
>
> llvm::MVT::getVectorType(llvm::MVT::ValueType, unsigned int))
>
> The following dependencies is not a singleton, but they it just seemed
> dubious to me that "TransformUtils" would depend on ScalarOpts.
> libLLVMTransformUtils.a:
> libLLVMScalarOpts.a
> llvm::LowerSelectID
> llvm::LowerSwitchID
> llvm::PromoteMemoryToRegisterID
>
> Something else that came up fairly often. Several libraries depend on
> libLLVMTarget.a solely to get at the TargetData class. Perhaps this
> should be moved to VMCore?
>
> Hope this helps resolve the cyclic dependencies in LLVM.
>
> Reid.
>
>
> _______________________________________________
> 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/