<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 25, 2008, at 11:29 PM, Nicolas Capens wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div lang="EN-US" link="blue" vlink="purple"><div class="Section1"><div style="margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Hi all,<o:p></o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">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…<o:p></o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">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?<o:p></o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">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?<o:p></o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div></div></div></span></blockquote><br></div><div>Hi Nicholas,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I'm sure that there are a ton of other similar things that can be done to squeeze it down.</div><div><br></div><div>-Chris </div></body></html>