Re: [lto] Streaming out language-specific DECL/TYPEs

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Michael Matz wrote:
> Hi,
>
> On Tue, 3 Jun 2008, Diego Novillo wrote:
>
>   
> > On Tue, Jun 3, 2008 at 04:51, Richard Guenther
> > <richard.guenther@gmail.com> wrote:
> >
> >     
> > > You may want to read
> > >
> > > http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00349.html
> > >       
> > Thanks.  I think I will try to incorporate this in LTO so we won't
> > even need to deal with these codes in the streamer.  Michael, are you
> > OK with this or were you going to work on this for mainline?
> >     
>
> I'm fine with that.  Note, though, that incorporating this potentially 
> breaks quite some things.  In particular debugging and thunks.  Due to the 
> hack for copying C++ classes also that will be broken.  I didn't get much 
> feedback about the thing in general so I stopped for the time being, but 
> at least some of the changes would also be usable for mainline.
>
> It adds a uid2type map on top of Richis uid2decl map, which I think is 
> also a nice thing to have in general.  But it has the same garbage 
> collection implications as Richis uid2decl map, in that it will break 
> bootstrap in mysterious ways, when something is collected between two 
> aliasing passes :-/
>
>
> Ciao,
> Michael.
>   
Note that michael's patch exposes some sleeping dragons for lto.  
Namely, if the debug information is generated early for these issues, 
then there will have to be code in lto which "copies" this information 
into the lto generated .o file.   I say "copies" because i do not know 
how smart this copying is going to have to be.   Hopefully it can be 
done without the need for any fe knowledge (I am also working on a 
genetically engineered flying pig).

On the other hand, we could translate this stuff into some fe 
generically homogenized gimple and serialize that. This sounds like fun 
also.

kenny