[LLVMdev] Why are LLVM libraries enormous?

[Óscar Fuentes]

Trevor Harmon <Trevor.W.Harmon at nasa.gov> writes:

> On Jul 27, 2010, at 4:11 PM, Óscar Fuentes wrote:
>
>> Why would be relevant that XCode produces library
>> files smaller than Visual Studio? Its comparing apples to oranges.
>
> The size of static libraries is relevant because it places an upper
> bound on the size of the executable.

This is not strictly true, as some compilers can generate code from the
library contents (think on a library containing LLVM bytecode, or a C++
library that relies on the linker for template instantiation.) But for
our purposes, let's accept that upper bound.

> Otherwise we can only speak anecdotally about "typical" executables
> that use "some" of the LLVM features.

That upper bound is useful just in the case where the combined size of
*all* the libraries looks small enough to you. OTOH, labeling a library
as fatware just looking at the size of the static libraries is wrong.

I'll say that the right method for estimating the size of a project that
uses LLVM is to determine the features you need (JIT? static code
generation? optimizations? backend(s)? etc) and to create an executable
that links then in. That is far more accurate than adding the file size
of static libraries.

> As for the apples-to-oranges comparison between GCC output and Visual  
> Studio output, having additional data points from other environments  
> may be helpful in understanding whether a size issue affects all  
> platforms or is specific to Visual Studio.

As mentioned before, this only makes sense for executable files. Of
course with debug info stripped, optimizations enabled and with the
runtime C/C++ libraries dynamically linked.