Dubious Library Dependencies

Project Infrastructure LLVM Dev List Archives
1

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.

2

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@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-Chris