[PATCH][RFC] Step 1 to a middle-end type-system

[Richard Guenther]

On Mon, 25 Jun 2007, Diego Novillo wrote:

> On 6/25/07 10:48 AM, Richard Guenther wrote:
> 
> >>> + 
> >>> +       /* Otherwise pointers/references are equivalent if their pointed
> >>> + 	 to types are effectively the same.  This allows to strip conversions
> >>> + 	 between pointer types with different type qualifiers.
> >>> + 	 ???  We should recurse here with
> >>> + 	 type_conversion_needed_p.  */
> >>> +       return !lang_hooks.types_compatible_p (TREE_TYPE (inner_type),
> >>> + 					    TREE_TYPE (outer_type));
> >> This is the part that I'm not sure how we are going to remove.
> > 
> > Well, we need to get rid of the langhook, so yes we are.  And it works
> > for me here.
> 
> I *know* we have to get rid of it.  I'm just not sure how.  What rules
> do we use for type compatiblity?  bitwise equality for TREE_TYPEs?  Same
> sizes?  How do we know whether MyType and Integer are compatible?

For some classes of types it is easy.  Like for integral types where we
have mode, signedness and precision.  For some it is slightly more
complicated.  Like for pointers where toplevel qualifiers actually
have a meaning in the middle-end, and the pointed to type has the
same problems as ... for the very complicated stuff.  Like for
random aggregates.  But for this we have well-established ways for the
frontend to communicate compatibleness - TYPE_MAIN_VARIANT is one,
TYPE_CANONICAL is another.

And unless we lower all aggregate accesses to (base-object, offset, type)
we cannot reasonably do structural analysis in the middle-end to determine
compatibleness either.  As we have to preserve FIELD_DECLs for component
accesses for example.

Now to say I have a local patched tree with _no_ call to 
types_compatible_p left in tree_ssa_useless_type_conversion_1 and that
only has one testsuite regression which I attribute to C++ FEs fault.
Not to say for all we don't test in the testsuite, like regressions
in optimizations.

Richard.