Richard Biener <rguent...@suse.de> writes: > On Tue, 4 Jan 2022, Richard Sandiford wrote: > >> Richard Biener <rguent...@suse.de> writes: >> > On Fri, 17 Dec 2021, Richard Sandiford wrote: >> > >> >> Prathamesh Kulkarni <prathamesh.kulka...@linaro.org> writes: >> >> > Hi, >> >> > The attached patch rearranges order of type-check for vec_perm_expr >> >> > and relaxes type checking for >> >> > lhs = vec_perm_expr<rhs1, rhs2, mask> >> >> > >> >> > when: >> >> > rhs1 == rhs2, >> >> > lhs is variable length vector, >> >> > rhs1 is fixed length vector, >> >> > TREE_TYPE (lhs) == TREE_TYPE (rhs1) >> >> > >> >> > I am not sure tho if this check is correct ? My intent was to capture >> >> > case when vec_perm_expr is used to "extend" fixed length vector to >> >> > it's VLA equivalent. >> >> >> >> VLAness isn't really the issue. We want the same thing to work for >> >> -msve-vector-bits=256, -msve-vector-bits=512, etc., even though the >> >> vectors are fixed-length in that case. >> >> >> >> The principle is that for: >> >> >> >> A = VEC_PERM_EXPR <B, C, D>; >> >> >> >> the requirements are: >> >> >> >> - A, B, C and D must be vectors >> >> - A, B and C must have the same element type >> >> - D must have an integer element type >> >> - A and D must have the same number of elements (NA) >> >> - B and C must have the same number of elements (NB) >> >> >> >> The semantics are that we create a joined vector BC (all elements of B >> >> followed by all element of C) and that: >> >> >> >> A[i] = BC[D[i] % (NB+NB)] >> >> >> >> for 0 ≤ i < NA. >> >> >> >> This operation makes sense even if NA != NB. >> > >> > But note that we don't currently expect NA != NB and the optab just >> > has a single mode. >> >> True, but we only need this for constant permutes. They are already >> special in that they allow the index elements to be wider than the data >> elements. > > OK, then we should reflect this in the stmt verification and only relax > the constant permute vector case and also amend the > TARGET_VECTORIZE_VEC_PERM_CONST accordingly.
Sounds good. > For non-constant permutes the docs say the mode of vec_perm is > the common mode of operands 1 and 2 whilst the mode of operand 0 > is unspecified - even unconstrained by the docs. I'm not sure > if vec_perm expansion is expected to eventually FAIL. Updating the > docs of vec_perm would be appreciated as well. Yeah, I guess de facto operand 0 has to be the same mode as operands 1 and 2. Maybe that was just an oversight, or maybe it seemed obvious or self-explanatory at the time. :-) > As said I prefer to not mangle the existing stmt checking too much > at this stage so minimal adjustment is prefered there. The PR is only an enhancement request rather than a bug, so I think the patch would need to wait for GCC 13 whatever happens. Thanks, Richard
