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.
