[cfe-dev] [LLVMdev] Windows debug builds require /bigobj

[Samuel Benzaquen]

On Thu, Aug 28, 2014 at 11:19 AM, Nico Weber <thakis at chromium.org> wrote:

> The dynamic matcher stuff also takes forever to compile – does the patch
> that's out for review to make /bigobj not required impact compile time too?
> I'd expect that it'd make things faster.
>

Some of the fixes we have done reduced the number of template
instantiations by adding some dynamic typing. This reduced the number of
symbols and should also reduce the compilation time, but we have not
focused on compilation time so far.
One idea we had some time ago was to split up the registration into N
files. This will reduce the number of objects per file and allow for
parallel compilation. It was not ultimately done because we found other
ways to stay below the symbol count limit.

_Sam


>
> On Thu, Aug 28, 2014 at 7:42 AM, Manuel Klimek <klimek at google.com> wrote:
>
>>
>>
>> On Tue Aug 26 2014 at 10:30:17 PM Aaron Ballman <aaron at aaronballman.com>
>> wrote:
>>
>>> On Tue, Aug 26, 2014 at 4:12 PM, David Majnemer
>>> <david.majnemer at gmail.com> wrote:
>>> > On Tue, Aug 26, 2014 at 12:43 PM, Samuel Benzaquen <sbenza at google.com>
>>> > wrote:
>>> >>
>>> >> On Tue, Aug 26, 2014 at 12:30 PM, Reid Kleckner <rnk at google.com>
>>> wrote:
>>> >>>
>>> >>> Mmmm, delicious template instantiation. This has come up before, and
>>> the
>>> >>> solution was to reduce the complexity of the template to avoid
>>> follow-on
>>> >>> instantiations like SmallVector<T>.
>>> >>
>>> >>
>>> >> In many cases, fixing this actually increases complexity of the code.
>>> >> For example, I have a change that removes ~16% of symbols by doing
>>> manual
>>> >> pointer deletion instead of using std::unique_ptr<>.
>>> >> I'll send the change for review.
>>> >>
>>> >> wrt whether LLVM should build without the /bigobj flag, that would be
>>> for
>>> >> someone else to decide.
>>> >
>>> >
>>> > I don't see any downside from switching /bigobj on; only ancient VS
>>> > toolchains do not support it.
>>>
>>> The last time this topic raised its head, the issue wasn't with
>>> turning on /bigobj (that's supported in MSVC 2005 and up), it was a
>>> question of why there was suddenly 37000 more sections in a single
>>> object file.
>>>
>>> If we're bumping up against this limit because of known, valid
>>> reasons, then I think /bigobj makes sense. If we're bumping up against
>>> it because there's a huge influx of sections in the object file, we
>>> may want to look at reducing that to keep build perf sane.
>>>
>>
>> So anybody not fine with using /bigobj for VS builds?
>>
>> Cheers,
>> /Manuel
>>
>>
>>>
>>> ~Aaron
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140828/f0d5a6f0/attachment.html>