We've observed that in the past few days, debug-builds with Visual Studio
have started failing again because too many sections are generated for
This has been observed and discussed before in this email thread:
It seems that since then, bit by bit, the number of sections for
has been creeping up. I've done a quick experiment on linux to measure how
the size and the number of sections in Registry.cpp.o has been increasing
time. The table does show that your fix in r183768 did reduce the number of
sections a lot; but since then, the number of sections has been increasing
steadily and quite rapidly.
Size of Register.cpp.o
svn id bytes sections
189448 27122264 28108
189353 27204656 28259
189031 26473624 27284
187500 26451288 26952
186000 21940824 23119
183769 19289872 20544
183768 33647984 35738
You did say on the previous email thread that you had a few more ideas on
to reduce the number of sections in Register.cpp.o. I'm wondering if you
be able to share the ideas you've got?
The problem is that there are a lot of AST nodes, and each node is getting
a whole bunch of classes instantiated, many of them with virtual methods.
For example, there are around 200 symbols related to clang::WhileStmt. It
instantiates TrueMatcher<clang::WhileStmt>, DynCastMatcher<clang::Stmt, ,
All of these have virtual methods, which means that there are 2 symbols per
constructor, 3 for the destructor and 1 for the vtable. This is without
counting the actual methods in the class.
We then do more method/class instantiations for the dynamic binding.
The main fix I wanted to try is to reduce the number of classes that get
instantiated. On the previous fix I removed vector<T> and list<T> for each
AST node. I just replaced those uses with plain arrays.
I will do another round of fixes. Do you have a target size/sections ?
At the moment, it seems clang cannot be build with visual studio in debug
mode; and the large file size of Register.cpp.o and the large number of
sections seems to be slowing down the compile process on other platforms
In the worst case we could use plan A, which was splitting Register.cpp
into many smaller files. We don't need to have all this code in the same
compilation unit. I wanted to avoid doing this because it doesn't help to
the total size of the objects and makes the code more complex.