On 11/28/2017 11:09 AM, Richard Sandiford wrote:
> 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).
OK. THanks for clarifying.
jeff
