Re: [PATCH] improve C++ code by changing fold-const.c

[Roger Sayle <roger at eyesopen dot com>]

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).


> > 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.


> Two because some of the more important optimizations that need to be
> implemented for good anti-abstraction in (at least) C++ and Java are
> type-based, and therefore require that we've not corrupted the type
> system.

As explained above, that C++ and Java require the same anti-abstraction
optimizations is the reason that types_compatible_p is inappropriate.

Roger
--