At the summit, I discovered two things about the internal representation of debugging information:
1) According to Honza, the instances of the BLOCK tree type take 30% of the space in a compilation. 2) The BLOCKS structure is linked in a way so that the blocks for one function link to the blocks of other functions. These two facts conspire to create a big problem for GCC/LTO, especially when we progress to trying to compile very large programs. Unlike many other essential parts of gcc, the current representation of debugging information is not one that can be divided into moderate sized pieces that can be processed independently. Honza's last lto patch "solves" the problem in the very short term by simply creating a single BLOCK for each function. This provides enough information to allow our testing to continue, but means that no useful debugging information will be generated. This is not acceptable in even the medium term, but it allows the problem to be deferred while Mark and I get the basics of reading and writing gimple working. I find it somewhat surprising that we need so many blocks. My experience is that in real programs few blocks actually have any local declarations and it appears that we do not bother to get rid of the blocks that have no local decls. However the biggest problem for lto is that when a procedure is inlined, the set of blocks for the inlined function is copied and the new copies have a cross link to the original version. It would help a lot if that pointer could be replaced with something like a pointer to a function decl and the dfs number of the block in the original function. I do not know the semantics of what is needed by the debuggers, but some representation where each function can be managed as a separate unit is going to be required to process large programs. Suggestions are welcome, but volunteers willing to attack this problem are truly needed. I do not think that anyone would take lto seriously if we cannot support debugging; only toy compilers do not have debugging. Kenny
