r260267 - Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp

[Aaron Ballman via cfe-commits]

On Tue, Feb 9, 2016 at 3:59 PM, Reid Kleckner <rnk at google.com> wrote:
> On Tue, Feb 9, 2016 at 12:32 PM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
>>
>> On Tue, Feb 9, 2016 at 2:53 PM, Reid Kleckner via cfe-commits
>> <cfe-commits at lists.llvm.org> wrote:
>> > Author: rnk
>> > Date: Tue Feb  9 13:53:30 2016
>> > New Revision: 260267
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=260267&view=rev
>> > Log:
>> > Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp
>> >
>> > This is the third time it has crossed the 2^16 section limit. We've
>> > already spent time optimizing this file to reduce template
>> > instantiations, and it's not clear that there is anymore low hanging
>> > fruit.
>>
>> Bummer. Do we have any mechanisms in place that will bark loudly at us
>> when we accidentally introduce a large quantity of symbols from this
>> file now? That has also happened a few times, and /bigobj warnings
>> were the primary way we were notified (since it's difficult to tell
>> from file size alone).
>
>
> 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.

It is definitely sub-optimal and arbitrary, yet it has pointed out
real problems in the past that we would be unlikely to catch as
quickly, so it was better than nothing. Note, I am not suggesting this
commit is inappropriate, just unfortunate.

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

That would definitely be useful functionality!

~Aaron