<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 9, 2016 at 12:32 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Feb 9, 2016 at 2:53 PM, Reid Kleckner via cfe-commits<br>
<<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<br>
> Author: rnk<br>
> Date: Tue Feb  9 13:53:30 2016<br>
> New Revision: 260267<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=260267&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=260267&view=rev</a><br>
> Log:<br>
> Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp<br>
><br>
> This is the third time it has crossed the 2^16 section limit. We've<br>
> already spent time optimizing this file to reduce template<br>
> instantiations, and it's not clear that there is anymore low hanging<br>
> fruit.<br>
<br>
</span>Bummer. Do we have any mechanisms in place that will bark loudly at us<br>
when we accidentally introduce a large quantity of symbols from this<br>
file now? That has also happened a few times, and /bigobj warnings<br>
were the primary way we were notified (since it's difficult to tell<br>
from file size alone).<br></blockquote><div><br></div><div>No, there isn't any mechanism. I think what we really should be worrying about is overall code size, and that this particular section count limit is arbitrary.</div><div><br></div><div>If we tackled the code size problem directly, we'd use a tool to highlight code that has a high source-line-to-code-byte ratio. I know Chromium has done this in the past to identify overly inlined functions and things that shouldn't be templates.</div></div></div></div>