Re: [middle-end] PR c/29092, vector types not compatible when they should be

[Roger Sayle <roger at eyesopen dot com>]

Hi Paolo,

On Wed, 27 Sep 2006, Paolo Bonzini wrote:
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01215.html
> 2006-09-25  Paolo Bonzini  <bonzini@gnu.org>
>
>	PR c/29092
>	* tree.c (make_vector_type): Memoize types.
>	(used_vector_types): New.

Hmm.  I'm not really happy with the way that you're using the front-end
specific types_compatible_p langhook to decide whether to create a new
VECTOR_TYPE node or not.  The middle-end, and particulary new type
construction in tree.c has/needs a stricter type system...


+    if (lang_hooks.types_compatible_p (TREE_TYPE (t), innertype)
+        && TYPE_VECTOR_SUBPARTS (t) == nunits
+	&& (mode == VOIDmode || mode == TYPE_MODE (t)))

I think instead of lang_hooks.types_compatible_p, it would be better
to ideally use (in order of preference):

(i) TREE_TYPE (t) == innertype

(ii) TREE_TYPE (t) == TYPE_MAIN_VARIANT (innertype)
     && TYPE_READONLY (t) == TYPE_READONLY (innertype)
     && TYPE_VOLATILE (t) == TYPE_VOLATILE (innertype)

(iii) TYPE_MODE (t) == TYPE_MODE (innertype)
     && TYPE_READONLY (t) == TYPE_READONLY (innertype)
     && TYPE_VOLATILE (t) == TYPE_VOLATILE (innertype)

(iv) TREE_TYPE (t) == TYPE_MAIN_VARIANT (innertype)

(v)  TYPE_MODE (t) == TYPE_MODE (innertype)


I suspect/hope that the first clause above is sufficient to resolve
PR c/29092, such that if the inner types are pointer identical then
we return a canonical VECTOR_TYPE tree, that remains pointer identical.

I also think this will also solve the problem you're encountering
with gcc.target/powerpc/20030218-1.c:

-  vint = vshort; /* { dg-error "incompatible types in assignment" } */

Just because the front-end says that it can convert a short to an int,
doesn't mean that the middle-end should consider vectors of shorts and
vectors of ints as identical/indistinguishable.



Perhaps a C front-end maintainer could also explain why this isn't
just working around a front-end bug in comptypes, that needs to use
a improved equivalence for vector types?  But I can see keeping and
returning canonical vector_type nodes in the middle-end helps improve
the "type1 == type2" fast-paths in many comparison routines.


One possibility, if the linked list starts getting a bit slow, is
to instead use a table of vector_type[innermode][width] for the common
small values:  [SImode][2], [SImode][4], [QImode][8], etc...  Then
fall back to your new used_vector_types list for everything else.
As hinted at above, this table is really effectively a hash-table,
as we'd like to keep the individual variants of each vector type to
correctly preserve the read-only and volatile bits, etc..

:REVIEWMAIL:

Roger
--