Richard Biener <richard.guent...@gmail.com> writes: > On Sun, Dec 10, 2017 at 12:06 AM, Richard Sandiford > <richard.sandif...@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, 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.) > 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. > 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. Thanks, Richard
