r241653 - Revert "Revert r241620 and follow-up commits" and move the initialization

[Adrian Prantl]

> On Jul 8, 2015, at 9:29 AM, Daniel Jasper <djasper at google.com> wrote:
> 
> This still seems quite bad to me:
> 
> --- cfe/trunk/tools/clang-check/CMakeLists.txt (original)
> +++ cfe/trunk/tools/clang-check/CMakeLists.txt Tue Jul  7 20:00:30 2015
> @@ -1,8 +1,24 @@
> -set(LLVM_LINK_COMPONENTS
> +set( LLVM_LINK_COMPONENTS
> +  ${LLVM_TARGETS_TO_BUILD}
> +  Analysis
> +  CodeGen
> +  Core
> +  IPA
> +  IPO
> +  InstCombine
> +  Instrumentation
> +  MC
> +  MCParser
> +  ObjCARCOpts
>    Option
> +  ScalarOpts
>    Support
> +  TransformUtils
> +  Vectorize
>    )
> 
> Have you look at how much this increases the binary size of clang-check, etc.?

At the moment this size increase affects only clang-check and c-index-test. An alternative that I considered was to force clang-check to use a different module cache than clang (and leave out the module object file container support), but that also means that clang-check wouldn’t be able to parse understand precompiled headers built with clang, which is actually something explicitly tested in the test suite.

That said, there are a couple of libraries in that list that look like we should definitely be able to get rid of (Instrumentation, and all the optimizations like ObjCArcOpts, ScalarOpts, Vectorize, ...) since we are only compiling metadata and no code.
I will investigate what’s necessary to get rid of these unnecessary dependencies.

-- adrian

> 
> On Wed, Jul 8, 2015 at 6:12 PM, Manuel Klimek <klimek at google.com <mailto:klimek at google.com>> wrote:
> On Wed, Jul 8, 2015 at 6:10 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
> 
>> On Jul 8, 2015, at 9:03 AM, Manuel Klimek <klimek at google.com <mailto:klimek at google.com>> wrote:
>> 
>> On Wed, Jul 8, 2015 at 5:53 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
>> > On Jul 8, 2015, at 5:04 AM, Manuel Klimek <klimek at google.com <mailto:klimek at google.com>> wrote:
>> >
>> > Daniel pointed out this introduces a new dependency onto codegen from tools that only need to parse - was this somehow already there earlier? What does this buy us? (I'm probably missing something :)
>> >
>> 
>> For module debugging we want to emit debug info for the data types defined by a clang module alongside the serialized clang ast when building pch/pcm files. This way we can avoid emitting tons of redundant types in the debug info of each object that was built against the module.
>> 
>> A tool that wants to parse *and* make use of clang modules or precompiled headers produced by clang will need to link against codegen. Tools that don’t want/need clang modules, or can use a separate module cache can continue to use the RawPCHContainerOperations without introducing any extra dependency. This currently true for all of clang-tools-extra, for example.
>> 
>> Thanks for explaining, that makes sense. Does debug info really need the full codegen library or only parts of it? (I have no idea how that part works ;)
> 
> I could be possible to split out CGDebugInfo, ObjectFilePCHContainerOperations, and BackendUtil into a separate library but looking at the include list in CGDebugInfo it looks like that would also pull in CGBlocks, CGCXXABI, CGObjCRuntime, CodeGenFunction, and CodeGenModule and I think then there is not that much left.
> It’s not impossible to split off a data-types-only CGDebugInfo base class to get rid of most of these dependencies, but that’s a larger project. 
> 
> Makes sense, thanks! 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150708/37902c98/attachment.html>