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

[Nico Weber]

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.


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/1c66c4cd/attachment.html>