Diego Novillo wrote:
> That's relevant at the language
>> syntactic/semantic level of validing such things as parameter lists, but to
>> GIMPLE two types are compatible if and only if they would produce the
>> identical RTL. So two integer types are compatible if they have the same
>> mode, precision, and bounds. Two FIELD_DECLs are compatible if they have the
>> same positions, aligments, sizes, and compatible types, two record types are
>> compatible if they have the same sizes and alignment and all fields are
>> compatible. Etc.
>>
>> The issue of debugging information is very different but I don't think in
>> the scope of this particular discussion.
>>
> Yup. That's been the idea all along. We represent all the FE language
> semantics in GIMPLE, much like we expose ctor/dtor in C++ or EH or any
> of the other language mechanisms.
>
> 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. 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.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
