[LLVMdev] Circular dependencies

[Chris Lattner]

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 .a

I'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.a

Codegen 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/