Extended Description

We want to eliminate cycles in the dependency graph of the LLVM libraries. llvm-config reports this,
and Reid has compiled this information. To get this info, use:

list of which libs/objs depend on which other ones:
GenLibDeps.pl -flat /path/to/Debug/lib > LibDeps.flat

full dependency listing including symbols:
GenLibDeps.pl -why /path/to/Debug/lib | c++filt > LibDeps.whyå

Here are some simple dependencies that can be snipped, this may be out-of-date:

The main cycle is this:
libLLVMAnalysis.a -> libLLVMCodeGen.a -> libLLVMScalarOpts.a ->
libLLVMSelectionDAG.a -> libLLVMTarget.a -> libLLVMTransformUtils.a ->
libLLVMipa.a -> libLLVMAnalysis.a

libLLVMAnalysis.a shouldn't depend on libLLVMCodeGen.a
libLLVMSelectionDAG.a shouldn't depend on libLLVMTransformUtils.a (it uses it for critical edge
breaking)
libLLVMTransformUtils.a shouldn't use LLVMipa (it uses/updates call-graph stuff)
libLLVMTarget.a uses libLLVMCodeGen.a for MVT::getVectorType (codegen should use target, not the
other way around)

LLVMIA64 uses intrinsic lowering? It shouldn't.

Maybe snippable:
libLLVMCodeGen uses Analysis only for loopinfo?

TransformUtils shouldn't depend on ScalarOpts. It currently does to get LowerSelectID, LowerSwitchID,
PromoteMemoryToRegisterID. We need to make a pass be able to "update" another pass without having
a strong dependency on that pass existing.

Thanks to Reid for collecting much of this data.

-Chris