Ping: RFA: Consider int and same-size short as equivalent vector components

Ping: RFA: Consider int and same-size short as equivalent vector components

[Joern Rennecke]

Apart from Paolo Carlini's suggestion to improve the wording of the ChangeLog,
this patch hasn't been reviewed for more than a week:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01634.html

Re: Ping: RFA: Consider int and same-size short as equivalent vector components

[Nathan Sidwell]

On 09/05/13 15:50, Joern Rennecke wrote:
> Apart from Paolo Carlini's suggestion to improve the wording of the ChangeLog,
> this patch hasn't been reviewed for more than a week:
> http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01634.html

I don't think the issue is whether they should be treated as equivalent, but 
whether there's an implicit promotion from (say) vec-of-int to vec-of-long. For 
instance, given:

int_vec_t i;
long_vec_t l;

if:
   s < l
is well formed, then think it reasonable for:
   void Foo (long_vec_t);
...
   Foo (i);
to be well formed too.  Is that true with your patch?

Now, what implicit promotions are permitted?  IIUC you're saying that promotions 
that don't change the element size are ok.  I'm fine with that (provided 
references aren't involved).

nathan

RFA: accept opaque vectors as compatible to same-size,same-element-size vectors in binary operations (Was: Re: Ping: RFA: Consider int and same-size short as equivalent vector components)

[Joern Rennecke]

Quoting Nathan Sidwell <nathan@acm.org>:

> On 09/05/13 15:50, Joern Rennecke wrote:
>> Apart from Paolo Carlini's suggestion to improve the wording of the  
>>  ChangeLog,
>> this patch hasn't been reviewed for more than a week:
>> http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01634.html

I suppose the original subject has become a bit misleading...
I've changed it in this replay, though it becomes quite a mouthful...

> I don't think the issue is whether they should be treated as
> equivalent, but whether there's an implicit promotion from (say)
> vec-of-int to vec-of-long. For instance, given:
>
> int_vec_t i;
> long_vec_t l;
>
> if:
>   s < l
> is well formed, then think it reasonable for:
>   void Foo (long_vec_t);
> ...
>   Foo (i);
> to be well formed too.  Is that true with your patch?

My patch doesn't touch this area.  First, what it changes is only type
checking for binary operators applied to vectors.  Second, the types
for which the type checking is relaxed are opaque vectors, types that
are generated by gcc as intermediate results, and, as I mentioned in
the patch posting, the documentation for TYPE_VECOR_OPAQUE says that
"the frontends should not emit warnings
    about missing conversions to other vector types of the same size."

Re: Ping: RFA: Consider int and same-size short as equivalent vector components

[Jason Merrill]

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?

Jason

Re: Ping: RFA: Consider int and same-size short as equivalent vector components

[Joern Rennecke]

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?

Re: Ping: RFA: Consider int and same-size short as equivalent vector components

[Jason Merrill]

On 09/06/2013 08:58 PM, Joern Rennecke wrote:
> 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.

Your earlier patch is OK if you add this information to the comments for 
the various functions and have them mention each other.

Jason