[llvm-commits] [llvm] r135760 - in /llvm/trunk: cmake/modules/LLVMLibDeps.cmake lib/Support/CMakeLists.txt lib/Support/TargetRegistry.cpp lib/Target/CMakeLists.txt lib/Target/TargetRegistry.cpp

[Evan Cheng]

Sorry about the late reply. I just got back.

On Aug 5, 2011, at 10:40 PM, Chandler Carruth wrote:

> On Mon, Aug 1, 2011 at 3:40 PM, Evan Cheng <evan.cheng at apple.com> wrote:
> I am not comfortable with a few weeks. Is it not possible to just move TargetRegistry.cpp back to Support?
> 
> Putting this into Support violates a lot of layering principles. I care a lot about layering and other invariants, thats how we keep building and using LLVM effectively.

What layering principles? TargetRegistry is for tools to use MC and Target components without needing to know the implementation details. IMO it should be in a component that all LLVM clients need to link in, which is support. If you are concerned about TargetRegistry.h including MC/MCCodeGenInfo.h, we can move those enums to eliminate the dependency.

> 
> Anyways, I understand the need for an expedient solution. I think I have a reasonable compromise -- we could move the registry into MC. The only targets that don't actually need MC are the CBackend and the CppBackend. That seems likely to be the ongoing trend. It would allow MC clients to not pull in any part of Target.
> 
> Best of all, that's where the other two pieces of the registry already live: the Reloc and CodeModel classes.
> 
> I'm trying this out now to ensure it actually works, and does in fact shrink llvm-mc back down to size.

This is less bad than putting it in Target but I just don't see how TargetRegistry is a MC concept. cc'ing Chris for his input on this.

Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110823/8fb80f62/attachment.html>