This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFD: language hooks in GIMPLE / lang_flag?


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.  


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]