This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH] improve C++ code by changing fold-const.c



On May 27, 2004, at 14:43, Roger Sayle wrote:


On Thu, 27 May 2004, Richard Henderson wrote:

On Thu, May 27, 2004 at 11:33:22AM -0600, Roger Sayle wrote:
But you'll also appreciate that this function should be independent of
the vagaries of the language front-end, and is therefore distinct
from lang_hook's types_compatible_p.

No, I do not appreciate that. I don't even know what you mean by that.
In my mind, types_compatible_p was created exactly in order to isolate
vagaries of the front-end that result in pointer equality not being
sufficient.

Why is types_compatible_p a lang_hook then? The default implementation in fortran and java is TYPE_MAIN_VARIANT(x) == TYPE_MAIN_VARIANT(y).

That is because it was wrong for C rules in term of structs and such and for intermodule optimizations, see why this was wrong when the language hook was added by Dale and why tree types become more important and can remove casts.


Type equivalence to the middle-end should be based upon the semantics
implemented by RTL expansion...

I disagree strongly.

One because rtl has no types and therefore no semantics at all.

Of course, RTL has no types only modes. But "RTL expansion" is the
process of converting trees, which do have types, into RTL. It is
this expansion that assigns the meaning to tree types: modes to variables,
REG_POINTER annotations, structure layout, etc... In the middle-end,
the main role of the type system is to avoid ICEing in RTL expansion.
The traditionally poor type preservation in "fold" is hidden by the
property that "RTL expansion" tolerates some level of type mismatch,
provided that the modes are compatible.

I would strongly disagree here now we have real tree level optimizations
more than just fold and tree inlining. Types now control more than the
just making sure that the expansion to RTL does not ICE (in fact we have
a type checker right after gimple phase to make sure that the types are
correct on the trees, I think we miss one or two cases still as we would
ICE later on if the tree produced by the front-end was wrong [gfortran has
this issue, I will be look into how to add this check]).


Type semantics should be well defined and I am trying to make a well defined
decision based on ADDR_EXPR<int&, a> is well defined by the documentation
in c-tree.texi.


Thanks,
Andrew Pinski


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