[cfe-dev] [LLVMdev] Windows debug builds require /bigobj
klimek at google.com
Thu Aug 28 07:42:26 PDT 2014
On Tue Aug 26 2014 at 10:30:17 PM Aaron Ballman <aaron at aaronballman.com>
> 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
> >>> solution was to reduce the complexity of the template to avoid
> >>> 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
> >> 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
> >> 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?
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev