debugging info considered harmful to lto.

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

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