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.
