Kenneth Zadeck wrote:
I am not so concerned with running out of virtual address space than I
am about being able to break this up so that it can be done in parallel,
on a farm of machines. Otherwise, lto can never be part of anyone's
compile/test loop.
I think we just expanded the scope of work by an order of magnitude. :-)
If you had just said that you wanted to support multi-threaded LTO, that
would have been a big deal. But multiple machines with multiple address
spaces trying to do LTO on one program is a really big deal. (Of
course, there is a "cheap hack" way of doing what you want: run LTO on
clumps of object files in parallel, and then just link the pre-optimized
files together in the ordinary way.)
I'd really like to see us inline a function before we even begin to have
this conversation. :-)
I have no idea how "stable" all the types and decls are over a
compilation. I write my info pretty early, and I assume the types and
decls are written pretty late in the compilation (otherwise you would
not have address expressions for the debugger). If there has been any
"processing" on these between when I write my stuff and when the types
and decls get written, things may not match up.
I don't think that this is an issue. The important information about
types and declaration is stable. Things like "is this declaration
used?" change over the course of the compilation, but that's not useful
for DWARF anyhow -- and, in general, we don't write out information
about types/declarations that are entirely unused. The key aspects
(sizes/layouts/etc.) are fixed.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
