Re: [076/nnn] poly_int: vectorizable_conversion

2017-12-05 Thread Jeff Law 
On 11/28/2017 11:09 AM, Richard Sandiford wrote:
> Jeff Law  writes:
>> On 10/23/2017 11:30 AM, Richard Sandiford wrote:
>>> This patch makes vectorizable_conversion cope with variable-length
>>> vectors.  We already require the number of elements in one vector
>>> to be a multiple of the number of elements in the other vector,
>>> so the patch uses that to choose between widening and narrowing.
>>>
>>>
>>> 2017-10-23  Richard Sandiford  
>>> Alan Hayward  
>>> David Sherwood  
>>>
>>> gcc/
>>> * tree-vect-stmts.c (vectorizable_conversion): Treat the number
>>> of units as polynomial.  Choose between WIDE and NARROW based
>>> on multiple_p.
>> If I'm reding this right, if nunits_in < nunits_out, but the latter is
>> not a multiple of the former, we'll choose WIDEN, which is the opposite
>> of what we'd do before this patch.  Was that intentional?
> 
> That case isn't possible, so we'd assert:
> 
>   if (must_eq (nunits_out, nunits_in))
> modifier = NONE;
>   else if (multiple_p (nunits_out, nunits_in))
> modifier = NARROW;
>   else
> {
>   gcc_checking_assert (multiple_p (nunits_in, nunits_out));
>   modifier = WIDEN;
> }
> 
> We already implicitly rely on this, since we either widen one full
> vector to N full vectors or narrow N full vectors to one vector.
> 
> Structurally this is enforced by all vectors having the same number of
> bytes (current_vector_size) and the number of vector elements being a
> power of 2 (or in the case of poly_int, a power of 2 times a runtime
> variant, but that's good enough, since the runtime invariant is the same
> in both cases).
OK.  THanks for clarifying.

jeff

Re: [076/nnn] poly_int: vectorizable_conversion

2017-11-28 Thread Richard Sandiford 
Jeff Law  writes:
> On 10/23/2017 11:30 AM, Richard Sandiford wrote:
>> This patch makes vectorizable_conversion cope with variable-length
>> vectors.  We already require the number of elements in one vector
>> to be a multiple of the number of elements in the other vector,
>> so the patch uses that to choose between widening and narrowing.
>> 
>> 
>> 2017-10-23  Richard Sandiford  
>>  Alan Hayward  
>>  David Sherwood  
>> 
>> gcc/
>>  * tree-vect-stmts.c (vectorizable_conversion): Treat the number
>>  of units as polynomial.  Choose between WIDE and NARROW based
>>  on multiple_p.
> If I'm reding this right, if nunits_in < nunits_out, but the latter is
> not a multiple of the former, we'll choose WIDEN, which is the opposite
> of what we'd do before this patch.  Was that intentional?

That case isn't possible, so we'd assert:

  if (must_eq (nunits_out, nunits_in))
modifier = NONE;
  else if (multiple_p (nunits_out, nunits_in))
modifier = NARROW;
  else
{
  gcc_checking_assert (multiple_p (nunits_in, nunits_out));
  modifier = WIDEN;
}

We already implicitly rely on this, since we either widen one full
vector to N full vectors or narrow N full vectors to one vector.

Structurally this is enforced by all vectors having the same number of
bytes (current_vector_size) and the number of vector elements being a
power of 2 (or in the case of poly_int, a power of 2 times a runtime
variant, but that's good enough, since the runtime invariant is the same
in both cases).

Thanks,
Richard

Re: [076/nnn] poly_int: vectorizable_conversion

2017-11-28 Thread Jeff Law 
On 10/23/2017 11:30 AM, Richard Sandiford wrote:
> This patch makes vectorizable_conversion cope with variable-length
> vectors.  We already require the number of elements in one vector
> to be a multiple of the number of elements in the other vector,
> so the patch uses that to choose between widening and narrowing.
> 
> 
> 2017-10-23  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * tree-vect-stmts.c (vectorizable_conversion): Treat the number
>   of units as polynomial.  Choose between WIDE and NARROW based
>   on multiple_p.
If I'm reding this right, if nunits_in < nunits_out, but the latter is
not a multiple of the former, we'll choose WIDEN, which is the opposite
of what we'd do before this patch.  Was that intentional?


jeff

[076/nnn] poly_int: vectorizable_conversion

2017-10-23 Thread Richard Sandiford 
This patch makes vectorizable_conversion cope with variable-length
vectors.  We already require the number of elements in one vector
to be a multiple of the number of elements in the other vector,
so the patch uses that to choose between widening and narrowing.


2017-10-23  Richard Sandiford  
Alan Hayward  
David Sherwood  

gcc/
* tree-vect-stmts.c (vectorizable_conversion): Treat the number
of units as polynomial.  Choose between WIDE and NARROW based
on multiple_p.

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   2017-10-23 17:22:40.906378704 +0100
+++ gcc/tree-vect-stmts.c   2017-10-23 17:22:41.879277786 +0100
@@ -4102,8 +4102,8 @@ vectorizable_conversion (gimple *stmt, g
   int ndts = 2;
   gimple *new_stmt = NULL;
   stmt_vec_info prev_stmt_info;
-  int nunits_in;
-  int nunits_out;
+  poly_uint64 nunits_in;
+  poly_uint64 nunits_out;
   tree vectype_out, vectype_in;
   int ncopies, i, j;
   tree lhs_type, rhs_type;
@@ -4238,12 +4238,15 @@ vectorizable_conversion (gimple *stmt, g
 
   nunits_in = TYPE_VECTOR_SUBPARTS (vectype_in);
   nunits_out = TYPE_VECTOR_SUBPARTS (vectype_out);
-  if (nunits_in < nunits_out)
-modifier = NARROW;
-  else if (nunits_out == nunits_in)
+  if (must_eq (nunits_out, nunits_in))
 modifier = NONE;
+  else if (multiple_p (nunits_out, nunits_in))
+modifier = NARROW;
   else
-modifier = WIDEN;
+{
+  gcc_checking_assert (multiple_p (nunits_in, nunits_out));
+  modifier = WIDEN;
+}
 
   /* Multiple types in SLP are handled by creating the appropriate number of
  vectorized stmts for each SLP node.  Hence, NCOPIES is always 1 in