Hi,
On Fri, 14 Jul 2006, Mark Mitchell wrote:
> > Everything must be explicitly represented in the IL, totally
> > independent from the input language.
>
> FWIW, I agree. However, I do not agree that two types are compatible
> iff they would produce identical RTL. GIMPLE should still know that
> "int" and "long" are distinct types (even if both 32 bits) since that
> permits alias analysis to do a better job.
Disagreement here, but see below.
> Similarly, "struct S { int i; }" and "struct T {int j; }" are not the
> same type.
>
> So, what should happen is that the front end should make these
> differences/similarities visible to the middle end via TYPE_ALIAS_SET,
> or some other mechanism *in the IL itself* rather than via a callback.
And agreement here :-) For the purposes of code generated type
equivalence should be structural equivalence, i.e. if they generate the
same code they should be treated equivalently. In fact we should be able
to do away with types at all at GIMPLE level (at least after LTO dumped
it's part and read it back), and only retain the scalar simple types. To
compensate for this loss of information every appropriate place would need
to be annotated with an alias number, which completely would specify the
frontends definition of the alias system, as required by the language.
Additionally an alias graph would need to be emitted by the frontend,
refering to those numbers. Those graphs would need to be merged from
different modules, and for _that_ purpose there needs to be a mapping to
the original types.
For purposes of disamiguating accesses inside loops we might need some
better annotation or mem-access primitives (carrying the indices), but
even them in the end don't need to know the full base types
(int/long/fortran INTEGER*4 don't matter, if the width and signedness are
the same, that would be encoded by the alias set number).
How that aliasing merging takes place can be specified by us in whatever
way we like. E.g. just a disjoint union (then all objects/accesses over
module borders would alias), or some intelligent unification of nodes
(e.g. based on type structure equivalence, or type name, or whatever).
I think that would very much help the inter language aspect of LTO.
Ciao,
Michael.
