Re: [00/13] Make VEC_PERM_EXPR work for variable-length vectors

[Richard Biener <richard.guenther@gmail.com>]

On Tue, Dec 12, 2017 at 4:32 PM, Richard Sandiford
<richard.sandiford@linaro.org> wrote:
> Richard Biener <richard.guenther@gmail.com> writes:
>> On Sun, Dec 10, 2017 at 12:06 AM, Richard Sandiford
>> <richard.sandiford@linaro.org> wrote:
>>> This series is a replacement for:
>>> https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00747.html
>>> based on the feedback that using VEC_PERM_EXPR would be better.
>>>
>>> The changes are:
>>>
>>> (1) Remove the restriction that the selector elements have to have the
>>>     same width as the data elements, but only for constant selectors.
>>>     This lets through the cases we need without also allowing
>>>     potentially-expensive ops.  Adding support for the variable
>>>     case can be done later if it seems useful, but it's not trivial.
>>>
>>> (2) Encode the integer form of constant selectors (vec_perm_indices)
>>>     in the same way as the new VECTOR_CST encoding, so that it can
>>>     cope with variable-length vectors.
>>>
>>> (3) Remove the vec_perm_const optab and reuse the target hook to emit
>>>     code.  This avoids the need to create a CONST_VECTOR for the wide
>>>     selectors, and hence the need to have a corresponding wide vector
>>>     mode (which the target wouldn't otherwise need or support).
>>
>> Hmm.  Makes sense I suppose.
>>
>>> (4) When handling the variable vec_perm optab, check that modes can store
>>>     all element indices before using them.
>>>
>>> (5) Unconditionally use ssizetype selector elements in permutes created
>>>     by the vectoriser.
>>
>> Why specifically _signed_ sizetype?  That sounds like an odd choice.  But I'll
>> eventually see when looking at the patch.
>
> Sorry, should have said.  The choice doesn't matter for vector lengths
> that are a power of 2,

which are the only ones we support anyway?

> but for others, using a signed selector means that
> -1 always selects the last input element, whereas for unsigned selectors,
> the element selected by -1 would depend on the selector precision.  (And the
> use of sizetype precision is pretty arbitrary.)

hmm, so you are saying that vec_perm <v1, v2, { -1, -2, ... }> is equal
to vec_perm <v1, v2, {2*n-1, 2*n-2, ....}?

tree.def defines VEC_PERM_EXPR via

   N = length(mask)
   foreach i in N:
     M = mask[i] % (2*N)
     A = M < N ? v0[M] : v1[M-N]

which doesn't reflect this behavior.  Does this behavior persist for variable
vector permutations?

>
>> Does that mean we have a VNDImode vector unconditionally for the
>> permute even though a vector matching the width of the data members
>> would work?
>
> A VECTOR_CST of N DIs, yeah.  It only becomes a VNDI at the rtl level
> if we're selecting 64-bit data elements.

And on GIMPLE?  Do we have a vector type with ssizetype elements
unconditionally?

>> What happens if the target doesn't have vec_perm_const but vec_perm to
>> handle all constant permutes?
>
> We'll try to represent the selector as VN?I, where ? matches the width
> of the data, but only after checking that that doesn't change the
> selector values.  So for current targets we'll use vec_perm for constant
> permutes as before, but we wouldn't for 2-input V256QI interleaves.

I see.

Richard.

> Thanks,
> Richard