Re: RFD: language hooks in GIMPLE / lang_flag?

[Diego Novillo <dnovillo at redhat dot com>]

Richard Kenner wrote on 07/12/06 14:33:
>> I don't understand what you are exactly trying to do, but I guess you
>> want to "virtualize" the lang-hooks?  The proper way to get rid of them
>> is to encode the information they provide in the IL, not to encode the
>> source language in the trees.
> 
> I strongly agree and was going to say so in response to the original message.
> 
> I think that having language hooks apply to GIMPLE is wrong.  I strongly
> believe that the semantics of GIMPLE ought to be defined very precisely and
> in a language-independent way.  With the exception of debugging information,
> I think this is true for types too: we define what the semantics of types are
> independent of any particular language.
> 
> For example, I've long felt that calling a lang hook to see if two types are
> "compatible" is quite wrong.  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.