Reid added some nice inter-library dependency data to utils/llvm- config/LibDeps.txt. There are three sets of circular dependencies between LLVM libraries. If you use any library from one of these sets, you may need to pull in the rest: LLVMCodeGen.o LLVMSelectionDAG.o libLLVMAnalysis.a libLLVMTarget.a libLLVMTransformUtils.a libLLVMipa.a LLVMSparcV9.o LLVMSparcV9InstrSched.o LLVMSparcV9ModuloSched.o LLVMSparcV9RegAlloc.o LLVMExecutionEngine.o LLVMInterpreter.o LLVMJIT.o The first set is the most problematic: It includes four *.a files, which means that certain linkers will tend to get confused unless you repeat '-l' flags. The odd entry here is libLLVMipa.a, which gets pulled in by something in libLLVMTransformUtils.a, but which doesn't often seem to be needed in practice. The third set is also a bit surprising: You always need to link in an interpreter, even when you have a perfectly good JIT. I hope this information amuses or informs someone. :-) Cheers, Eric
Hi Eric, Its definitely amusing :) About the only thing I can suggest are: 1. Combine LLVMSparc*.o into one LLVMSparc.a. That work is already happening with the new Sparc backend that is being developed. Should be out in 1.7 (Chris?) 2. Combine the JIT/Interpreter/ExecutionEngine into one .a I don't know enough about the codegen/target/analysis/ipa stuff to be able to make any suggestions. Perhaps Chris can shed some light. Reid. On Tue, 2006-03-21 at 18:29 -0500, Eric Kidd wrote:> Reid added some nice inter-library dependency data to utils/llvm- > config/LibDeps.txt. > > There are three sets of circular dependencies between LLVM libraries. > If you use any library from one of these sets, you may need to pull > in the rest: > > LLVMCodeGen.o LLVMSelectionDAG.o libLLVMAnalysis.a libLLVMTarget.a > libLLVMTransformUtils.a libLLVMipa.a > > LLVMSparcV9.o LLVMSparcV9InstrSched.o LLVMSparcV9ModuloSched.o > LLVMSparcV9RegAlloc.o > > LLVMExecutionEngine.o LLVMInterpreter.o LLVMJIT.o > > The first set is the most problematic: It includes four *.a files, > which means that certain linkers will tend to get confused unless you > repeat '-l' flags. > > The odd entry here is libLLVMipa.a, which gets pulled in by something > in libLLVMTransformUtils.a, but which doesn't often seem to be needed > in practice. > > The third set is also a bit surprising: You always need to link in an > interpreter, even when you have a perfectly good JIT. > > I hope this information amuses or informs someone. :-) > > 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/20060321/16e61488/attachment.sig>
On Tue, 21 Mar 2006, Reid Spencer wrote:> About the only thing I can suggest are: > > 1. Combine LLVMSparc*.o into one LLVMSparc.a. That work is already > happening with the new Sparc backend that is being developed. Should be > out in 1.7 (Chris?)I wouldn't worry about the SparcV9 backend for your project.> 2. Combine the JIT/Interpreter/ExecutionEngine into one .aI'd much rather change the code so that interpreter depends on EE and JIT depends on EE, but EE depends on neither of them. This would allow people to link just the JIT or just the interpreter into their apps, instead of always having both or none.> I don't know enough about the codegen/target/analysis/ipa stuff to be > able to make any suggestions. Perhaps Chris can shed some light.>> LLVMCodeGen.o LLVMSelectionDAG.o libLLVMAnalysis.a libLLVMTarget.a >> libLLVMTransformUtils.a libLLVMipa.aCodegen and SelectionDAG can be merged, either physically in the source base or treated as one thing in your code. 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. -Chris> > Reid. > > On Tue, 2006-03-21 at 18:29 -0500, Eric Kidd wrote: >> Reid added some nice inter-library dependency data to utils/llvm- >> config/LibDeps.txt. >> >> There are three sets of circular dependencies between LLVM libraries. >> If you use any library from one of these sets, you may need to pull >> in the rest: >> >> LLVMCodeGen.o LLVMSelectionDAG.o libLLVMAnalysis.a libLLVMTarget.a >> libLLVMTransformUtils.a libLLVMipa.a >> >> LLVMSparcV9.o LLVMSparcV9InstrSched.o LLVMSparcV9ModuloSched.o >> LLVMSparcV9RegAlloc.o >> >> LLVMExecutionEngine.o LLVMInterpreter.o LLVMJIT.o >> >> The first set is the most problematic: It includes four *.a files, >> which means that certain linkers will tend to get confused unless you >> repeat '-l' flags. >> >> The odd entry here is libLLVMipa.a, which gets pulled in by something >> in libLLVMTransformUtils.a, but which doesn't often seem to be needed >> in practice. >> >> The third set is also a bit surprising: You always need to link in an >> interpreter, even when you have a perfectly good JIT. >> >> I hope this information amuses or informs someone. :-) >> >> 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/