[LLVMdev] Circular dependencies

[Chris Lattner]

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.

-Chris


> 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.
>>
>> Reid.
>>
>> 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
>>>>>> libLLVMTarget.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:
>>>
>>>    __ZN4llvm11BasicAAStubEv
>>>
>>> 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!
>>>
>>> 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/