<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 27, 2013 at 2:12 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On Thu, Dec 26, 2013 at 10:04 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><br><div class="gmail_quote">On Fri, Dec 27, 2013 at 1:02 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Have you checked the other binary size reductions? I wonder why we didn't do this sooner.</div>


</div><div class="gmail_extra"></div></blockquote></div><br></div>Oh, of course, you did this just for clang-format.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Can we instead do this for all LLVM projects by default, and opt maybe 'clang', 'opt', 'llc', and 'bugpoint' out of it to support dlopen'ed passes and plugins?</div>


</div>
</blockquote></div><br></div><div class="gmail_extra">Something like the attached patch? (Make-only again, but now including the linux bits. If folks like it, I can do the cmake part as a followup.)</div><div class="gmail_extra">

<br></div><div class="gmail_extra">This adds -ffunction-sections -fdata-sections unconditionally, since most tools have few source files anyways and mostly link in static libs. This reduces the size of e.g. diagtool from 21 MB to 2.8 MB and clang-format from 22 MB to 1.8 MB (these numbers are on Linux). libclang.so drops from 29MB to 20MB, but from skimming through `vim -d <(nm old-libclang.so) <(nm new-libclang.so)` only mangled symbols are getting dropped, and the libclang makefile sets EXPORTED_SYMBOL_FILE, and tests pass, so hopefully nothing necessary is getting dropped.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">The size of libclang.a grows from 1.6 MB to 2 MB, as you'd expect with -ffunction-sections. The size of other .a files increases similarly: libclangARCMigrate goes from 5.9 MB to 8.9 MB, libclangAST.a from 8.1 MB to 11 MB, and so on. This is probably acceptable?</div>
</div></blockquote></div><br>This seems very reasonable to me for the advantages it poses. I even expect link times to go *down* as a consequence. Rock!</div><div class="gmail_extra"><br></div><div class="gmail_extra">Feel free to submit, and submit the cmake variant whenever you have it. The bots can catch the fallout. =D</div>
</div>