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: Ping: RFA: Consider int and same-size short as equivalent vector components


Quoting Jason Merrill <jason@redhat.com>:

On 09/05/2013 10:50 AM, Joern Rennecke wrote:
	(vector_types_compatible_elements_p): New function.

Why do we need this as well as vector_types_convertible_p?  For that
matter, why do we need both vector_types_convertible_p and
vector_targets_convertible_p?

vector_targets_convertible_p is used for pointer types.  The callers
do a hop, skip and dance to check that the qualifiers are satisfactory,
while OTOH vector_targets_convertible_p ignores the number of elements
in the vectors.  That's fine with vectors as we can consider, say,
a vector of 8 elements as two consecutive vectors of 4 elements, and
that works fine with pointers.

vector_types_convertible is used for pointer value types.
It could in principle call vector_targets_convertible_p as a subroutine,
but then the check for vector type would be duplicated with its callers,
and also the purpose of vector_targets_convertible_p would become
muddled.
Where vector_types_convertible returns true, a conversion might still be
needed to make the types match.

vector_types_compatible_elements_p was supposed to be a minimal change
from same_scalar_type_ignoring_signedness to fix the treatment of
opaque vectors in binary operators.  Where it returns true, and
the other checks of the caller succeed (being vector types in he first
place, and matching number of elements), we can just treat the types
as essentially the same.

I suppose we could replace same_scalar_type_ignoring_signedness / vector_types_compatible_elements_p by vector_compatible_p, but that would
change the behaviour in a number of ways.  First, we would no longer allow
sign changes by default, this would be only available with
-flax-vector-conversions, and to the extend that the types_compatible_p
lang hook says so; OTOH, whatever else it says is compatible, would then
also be (as long as -flax-vector-conversions is in effect).
Is that change wanted?
Also, we would presumably need to insert conversions at times.
And should we allow different-sized vectors to match?  If so, what would
be the result type?


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