Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Mark Mitchell wrote:
> 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 intention in expanding the scope of the work.  I just am not
going to do anything that precludes doing this.  As long as the function
bodies are in a form that can be easily accessed without reading and
processing the entire file, I am fine. 


>
>> 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.
>
You are either right, or we will fix it.  Those are the only two
options.  My only point was that there is a lot of compiler in between
where someone could have done something silly.