Windows /bigobj

Hi,

Recently one Windows build bot failed by my commit, because the obj file being generated is too big:

C:\ps4-buildslave2\llvm-clang-x86_64-expensive-checks-win\llvm\tools\clang\unittests\AST\ASTImporterTest.cpp : fatal error C1128: number of sections exceeded object file format limit: compile with /bigobj

Is there an LLVM policy to limit the maximum size of the generated obj files?
If not then I suspect the only solution is to turn on /bigobj on the build bot, right?
(Of course, I could refactor the cpp file to several smaller ones, but how do I know where to cut it?)

Thanks,
Gabor

Hi,

Recently one Windows build bot failed by my commit, because the obj file being generated is too big:

C:\ps4-buildslave2\llvm-clang-x86_64-expensive-checks-win\llvm\tools\clang\unittests\AST\ASTImporterTest.cpp : fatal error C1128: number of sections exceeded object file format limit: compile with /bigobj

Is there an LLVM policy to limit the maximum size of the generated obj files?

We usually try to limit it in cases where it makes sense to do so.
e.g., for a while we would put in efforts to reduce the number of
template instantiations to help avoid this problem. However, I believe
we only do that up to a point.

If not then I suspect the only solution is to turn on /bigobj on the build bot, right?

We already required that for some files; we turn on /bigobj support
for several files in Clang. We usually only do this on a file-by-file
basis though, so we can be alerted when new files are causing
problems.

~Aaron

rL349357 - we manually add /bigobj quite a bit to fix this sort of thing. Although I don’t think anyone ever goes around to check if any entries can ever be removed again…

rL349357 - we manually add /bigobj quite a bit to fix this sort of thing. Although I don't think anyone ever goes around to check if any entries can ever be removed again...

We usually ask the entries to be removed first and then use /bigobj
only when there's not another reasonable option. Since this is a test
file, I think it's fine to enable and move on.

~Aaron

Hi Aaron, thanks for your answer.

We usually try to limit it in cases where it makes sense to do so.

e.g., for a while we would put in efforts to reduce the number of
template instantiations to help avoid this problem. However, I believe
we only do that up to a point.

The corresponding file is a unittest file “ASTImporterTest.cpp” with many gtest macros, which I suspect do quite many template instantiations.
I don’t think it would be easy to reduce the size in this case, but I am open to any idea.
Is it okay to connect with the buildbot owner and ask for /bigobj for this file? Who should approve such decisions?

Thanks,
Gabor

Hi Aaron, thanks for your answer.

> We usually try to limit it in cases where it makes sense to do so.
e.g., for a while we would put in efforts to reduce the number of
template instantiations to help avoid this problem. However, I believe
we only do that up to a point.

The corresponding file is a unittest file "ASTImporterTest.cpp" with many gtest macros, which I suspect do quite many template instantiations.
I don't think it would be easy to reduce the size in this case, but I am open to any idea.
Is it okay to connect with the buildbot owner and ask for /bigobj for this file? Who should approve such decisions?

This is done on a file-by-file basis rather than a bot-by-bot basis.
Simon made the recommended changes in r349357 by updating the CMake
file to properly add the flag to just ASTImporterTest.cpp, so
everything should be in a good state now.

~Aaron