[076/nnn] poly_int: vectorizable_conversion

[Richard Sandiford]

Jeff Law <law@redhat.com> 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  <richard.sandiford@linaro.org>
>> 	    Alan Hayward  <alan.hayward@arm.com>
>> 	    David Sherwood  <david.sherwood@arm.com>
>> 
>> 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