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

[Manuel Klimek]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140828/4d023701/attachment.html>