[LLVMdev] Why are LLVM libraries enormous?

Török Edwin edwintorok at gmail.com
Thu Jul 29 00:05:31 PDT 2010


On Wed, 28 Jul 2010 10:57:02 -0700
Reid Kleckner <reid.kleckner at gmail.com> wrote:

> On Wed, Jul 28, 2010 at 9:01 AM, David Piepgrass
> <dpiepgrass at mentoreng.com> wrote:
> >> A LLVM JIT compiler for x86 under 1 MB? I doubt it is possible
> >> without a major rewriting of LLVM.
> >
> > Even with no optimizations? Drat. That means I can't use it.
> 
> Why?  I'd never checked, but I always assumed the LLVM JIT was much
> larger than 3.4 MB.

It is ~4.8M here.
Here are some size comparisons from ClamAV on Linux:
without JIT, -m32, -Os, stripped: 835K
with JIT, -m32, -Os, stripped: 5.6M
with JIT, -m64, -O2, stripped: 8.8M

If LLVM is compiled with debug info, and not stripped then it can be as
big as 70MB.

The JIT of course includes the code to generate LLVM IR for x86, and do
some minimal optimizations on it (mem2reg, dce).

On Tue, 27 Jul 2010 16:49:14 -0600
David Piepgrass <dpiepgrass at mentoreng.com> wrote:

> Why is the size of static libraries a "nonsensical" topic of
> discussion?

Because they include copies of the same code multiple times.
When you link an executable you only get 1 copy.
Think of templates being instantiated in different files with the same
type.
They also include symbol (and perhaps debug) information on Linux. 
I think VS keeps symbols separate. 

A more useful upper bound for size would be to create a shared library
from all of LLVM.

On Wed, 28 Jul 2010 21:56:58 +0200
Óscar Fuentes <ofv at wanadoo.es> wrote:

> 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.

Agreed, once you've chosen what features you need, the LLVM code you
link in will be about the same size.

Best regards,
--Edwin




More information about the llvm-dev mailing list