[LLVMdev] LLVM project binary size

[Nicolas Capens]

Hi Chris,

 

Thanks for the info. I'll probably try disabling the Intel and AT&T asm
printers then, once I have everything else going for my project. I'll get
back on this topic in due time to see what the other potential size reducing
measures are. I was just hoping maybe there are some simple options already
available, but I don't mind stepping up and doing it myself if I can get
some guidelines.

 

Cheers,

 

Nicolas

 

P.S: It's Nicolas, not Nicholas ;-)

 

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Chris Lattner
Sent: Wednesday, 28 May, 2008 08:02
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] LLVM project binary size

 

 

On May 25, 2008, at 11:29 PM, Nicolas Capens wrote:





Hi all,

 

I'm a little bit worried about the sheer size of the resulting binaries of a
project using LLVM. The medium large project for which I'm planning to use
it (which currently uses a custom dynamic code generator), produces a
compact 1.6 MB binary. When I compile LLVM's simple 'Fibonacci' example
project the executable is 2.6 MB.

 

I realize LLVM is a complex and feature rich project but could anyone give
me a rough idea of where most of the executable size is coming from, and
maybe give some ideas on how to reduce it if possible?

 

It's not like 2.6 MB is huge but it just seems disproportionate and I'd like
to keep my project lightweight (it could be used for embedded systems one
day). Note that I'm basically only using the IRBuilder, JIT, and a few
common optimization passes. Removing the optimizations doesn't seem to
affect the executable size at all, so I'm starting to wonder whether there
are a lot of other unused features ending up in the binary (I'm using Visual
C++ 2005 by the way, which is supposed to be quite good at reducing code
size). Maybe there is some way to explicitly disable unused features (not
compile them or use stubs)? I'm also under the impression that LLVM uses a
lot of static (pre-generated) tables, and maybe they could be somewhat
smaller when making some extra assumptions?

 

 

Hi Nicholas,

 

As others have mentioned, the first step is to find out what is consuming
the size.  We have done some work to reduce code size, but there is still a
lot that we can do.  For example, we know that killing off the last few uses
or RTTI info will shrink generated code size by 5-10% or so.

 

There are other refactorings that can be done to reduce executable size.
Specifically, if you're using a JIT, there is no reason to link in the code
to do .s file printing (and X86 has two versions of this code).  This code
is non-trivial and pulls in some big string tables.  Getting this out of the
JIT code footprint would require refactoring the asmprinter stuff so that it
isn't accessible via the X86 target's vtable.  This is very doable, but
noone has stepped up to do it yet.

 

I'm sure that there are a ton of other similar things that can be done to
squeeze it down.

 

-Chris 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080528/262a03db/attachment.html>