[LLVMdev] Circular dependencies
sabre at nondot.org
Thu Mar 23 22:27:47 PST 2006
On Wed, 22 Mar 2006, Reid Spencer wrote:
> Am I right in assuming that the goal here is to get libTransformUtils to
> depend on nothing in libTransforms or libAnalysis? If so, its going to
> take some significant code rearrangement.
> Perhaps a lib/Analysis/Utils is in order?
I think it's ok for TransformUtils to depend on Analysis. Having
xformations depend on analyses is ok, we just don't want the opposite.
> On Wed, 2006-03-22 at 08:13 -0800, Reid Spencer wrote:
>> Okay, the problem with this cycle is LoopSimplify. It is using
>> AliasAnalysis which is where that _ZN4llvm11BasicAAStubEv symbol is
>> coming from. It seems to me that LoopSimplify.cpp is in the wrong
>> place. This file defines the LoopSimplify FunctionPass which doesn't
>> seem to me to be a "transform util". I thought the purpose of
>> "Transforms/Util" was to provide utilities that are common amongst
>> transforms. But, LoopSimplyf *is* a transform. So, I think the solution
>> is to move LoopSimplify.cpp out of Transforms/Utils to somewhere else,
>> say just "Transforms. By doing this, we probably eliminate the cycle.
>> I'm going to validate that shortly.
>> On Wed, 2006-03-22 at 09:26 -0500, Eric Kidd wrote:
>>> On Mar 21, 2006, at 11:23 PM, Chris Lattner wrote:
>>>>>> LLVMCodeGen.o LLVMSelectionDAG.o libLLVMAnalysis.a
>>>>>> libLLVMTransformUtils.a libLLVMipa.a
>>>> 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.
>>> Yeah, I'm definitely having headaches with LLVMTransformUtils, which
>>> needs to appear before LLVMAnalysis and lLLVMTarget.
>>> -lLLVMTransformUtils -lLLVMAnalysis -lLLVMTarget
>>> If I don't do this, I get link errors on:
>>> I think, for now, the only portable workaround is for me to link all
>>> the *.a libraries in that loop twice, and hope we can clean up the
>>> dependencies later.
>>> There's several places where llvm-config could be simplified quite a
>>> bit if we broke the unnecessary dependencies and merged the remaining
>>> loops into single *.a files. In some sense, parts of llvm-config are
>>> re-inventing the system linker. Depending on your point of view, this
>>> might be a bad thing. :-)
>>> Many thanks to everyone who's helped sort this out!
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev