Windows debug builds require /bigobj

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.

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.

_Sam

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.

~Aaron

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.

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

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.

+1 to this.

Also, MinGW probably doesn't support /bigobj, so we will hit the problem
there if we haven't already.

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

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.

+1 to this.

Also, MinGW probably doesn't support /bigobj, so we will hit the problem
there if we haven't already.

I believe trunk MinGW actually does:
https://sourceware.org/ml/binutils/2014-03/msg00110.html

Just submitted rL217152 that reduces the numbers of symbols significantly,
as well as compile time and object byte size.
Please let me know if that puts us back under the threshold for MSVC.

_Sam

I just tested a MinGW debug build or your recent commit and it compiled fine. Previously, it couldn’t finish the compilation because my MinGW gcc/binutils don’t have support for /bigobj.