[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