[LLVMdev] Dubious Library Dependencies
Reid Spencer
rspencer at reidspencer.com
Tue Jul 25 15:44:37 PDT 2006
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:
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.
More information about the llvm-dev
mailing list