This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] improve C++ code by changing fold-const.c
- From: Andrew Pinski <pinskia at physics dot uc dot edu>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Andrew Pinski <pinskia at physics dot uc dot edu>, Richard Henderson <rth at redhat dot com>, <gcc-patches at gcc dot gnu dot org>, Mark Mitchell <mark at codesourcery dot com>, <law at redhat dot com>
- Date: Thu, 27 May 2004 14:59:27 -0400
- Subject: Re: [PATCH] improve C++ code by changing fold-const.c
- References: <Pine.LNX.email@example.com>
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
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
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
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
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
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
decision based on ADDR_EXPR<int&, a> is well defined by the