Jeff Law <l...@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.sandif...@linaro.org>
>> Alan Hayward <alan.hayw...@arm.com>
>> David Sherwood <david.sherw...@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
