lto gimple types and debug info

[Michael Matz]

Hi,

On Fri, 25 Jul 2008, Chris Lattner wrote:

> >But not all the trees implementing those types (and all the 
> >cross-references between those, that are important for parsing but not 
> >interesting at all for the middle-end).  All you need is a tag (alias 
> >set number) per type and a graph giving the conflicts between those 
> >tags.
> 
> With that level of information,

[Of course I wasn't saying that alias tags would be the _only_ information 
we would store about types, but the only important one for retaining 
useful aliasing info]

> how do you "link" the alias trees for different modules at LTO time?

You merge the graphs, create cross module conflicts, and possibly can 
collapse some nodes into one, namely when both are associated with the 
"same" type.

You need a way to recognize certain types as "the same".  There are 
several means to do that (let A and B be two modules):
1) no cross-module type is the same --> create conflicts between all
   types(A) and types(B), 
2) name-based type equality, works for a subset of languages, those nodes 
   only generate one node in the destination graph (and hence no conflict 
   between them)
3) structural equality, is not correct for many languages
4) special cases; e.g. the compiler "knowing" that fortran REAL*8 and C's 
   double is the same.

and some in between.  Of course that is the important thing to ask for a 
type system: "when are two types the same".  Everything follows from that, 
including how to deal with aliasing.  Hence we need to make sure that what 
we store about types let's us answer this question conservatively correct.  

Storing everything the trees contain doesn't even help here, as even that 
one only allows to answer the same-ness test inside one module (as can be 
seen by the hacks required to make -combine work, and that was only C).  

When discussing about the middle-end type system (i.e. the one implemented 
in useless_type_conversion_p) we defined type equality in terms of 
operations applicable to values of that type.  That's unfortunately not 
possible for real cross-module (and even cross-language) modules that 
define types explicitely via their layout and attributes, not implicitely 
by their operations (though we can infer operations for simple types).


Ciao,
Michael.