On Mon, 9 May 2022 at 19:22, Richard Sandiford wrote: > > Prathamesh Kulkarni writes: > > On Tue, 3 May 2022 at 18:25, Richard Sandiford > > wrote: > >> > >> Prathamesh Kulkarni writes: > >> > On Tue, 4 Jan 2022 at 19:12, Richard Sandiford > >> > wrote: > >> >> > >> >> Richard Biener writes: > >> >> > On Tue, 4 Jan 2022, Richard Sandiford wrote: > >> >> > > >> >> >> Richard Biener writes: > >> >> >> > On Fri, 17 Dec 2021, Richard Sandiford wrote: > >> >> >> > > >> >> >> >> Prathamesh Kulkarni writes: > >> >> >> >> > Hi, > >> >> >> >> > The attached patch rearranges order of type-check for vec_perm_expr > >> >> >> >> > and relaxes type checking for > >> >> >> >> > lhs = vec_perm_expr > >> >> >> >> > > >> >> >> >> > 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 ; > >> >> >> >> > >> >> >> >> 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. > >> > Hi, > >> > In attached patch, the type checking is relaxed only if mask is constant. > >> > Does this look OK ? > >> > > >> > Thanks, > >> > Prathamesh > >> >> > >> >> Thanks, > >> >> Richard > >> > > >> > diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc > >> > index e321d929fd0..02b88f67855 100644 > >> > --- a/gcc/tree-cfg.cc > >> > +++ b/gcc/tree-cfg.cc > >> > @@ -4307,6 +4307,24 @@ verify_gimple_assign_ternary (gassign *stmt) > >> > break; > >> > > >> > case VEC_PERM_EXPR: > >> > + /* If permute is constant, then we allow for lhs and rhs > >> > + to have different vector types, provided: > >> > + (1) lhs, rhs1, rhs2, and rhs3 have same element type. > >> > >> This isn't a requirement for rhs3. > >> > >> > + (2) rhs3 vector has integer element type. > >> > + (3) len(lhs) == len(rhs3) && len(rhs1) == len(rhs2). */ > >> > + > >> > + if (TREE_CONSTANT (rhs3) > >> > + && VECTOR_TYPE_P (lhs_type) > >> > + && VECTOR_TYPE_P (rhs1_type) > >> > + && VECTOR_TYPE_P (rhs2_type) > >> > + && VECTOR_TYPE_P (rhs3_type) > >> > + && TREE_TYPE (lhs_type) == TREE_TYPE (rhs1_type) > >> > + && TREE_TYPE (lhs_type) == TREE_TYPE (rhs2_type) > >> > + && INTEGRAL_TYPE_P (TREE_TYPE (rhs3_type)) > >> > + && known_eq (TYPE_VECTOR_SUBPARTS (lhs_type), TYPE_VECTOR_SUBPARTS (rhs3_type)) > >> > + && known_eq (TYPE_VECTOR_SUBPARTS (rhs1_type), TYPE_VECTOR_SUBPARTS (rhs2_type))) > >> > + return false; > >> > + > >> > >> I think this should be integrated into the existing conditions > >> rather than done as an initial special case. > >> > >> It might make sense to start with: > >> > >> if (TREE_CODE (rhs1_type) != VECTOR_TYPE > >> || TREE_CODE (rhs2_type) != VECTOR_TYPE > >> || TREE_CODE (rhs3_type) != VECTOR_TYPE) > >> { > >> > >> but expanded to test lhs_type too. Then the other parts of the new test > >> should be distributed across the existing conditions. > >> > >> The type tests should use useless_type_conversion_p rather than ==. > > Hi Richard, > > Thanks for the suggestions. In the attached patch, I tried to > > distribute the checks > > across existing conditions, does it look OK ? > > I am not sure how to write tests for the type checks tho, does > > gimple-fe support vec_perm_expr ? > > I did a quick testsuite run for vect.exp and the patch doesn't seem to > > cause any unexpected failures. > > > > Thanks, > > Prathamesh > >> > >> Thanks, > >> Richard > >> > >> > >> > >> > if (!useless_type_conversion_p (lhs_type, rhs1_type) > >> > || !useless_type_conversion_p (lhs_type, rhs2_type)) > >> > { > > > > diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc > > index e321d929fd0..a845c7fff93 100644 > > --- a/gcc/tree-cfg.cc > > +++ b/gcc/tree-cfg.cc > > @@ -4307,18 +4307,14 @@ verify_gimple_assign_ternary (gassign *stmt) > > break; > > > > case VEC_PERM_EXPR: > > - if (!useless_type_conversion_p (lhs_type, rhs1_type) > > - || !useless_type_conversion_p (lhs_type, rhs2_type)) > > - { > > - error ("type mismatch in %qs", code_name); > > - debug_generic_expr (lhs_type); > > - debug_generic_expr (rhs1_type); > > - debug_generic_expr (rhs2_type); > > - debug_generic_expr (rhs3_type); > > - return true; > > - } > > + /* If permute is constant, then we allow for lhs and rhs > > + to have different vector types, provided: > > + (1) lhs, rhs1, rhs2 have same element type. > > + (2) rhs3 vector has integer element type. > > + (3) len(lhs) == len(rhs3) && len(rhs1) == len(rhs2). */ > > > > - if (TREE_CODE (rhs1_type) != VECTOR_TYPE > > + if (TREE_CODE (lhs_type) != VECTOR_TYPE > > + || TREE_CODE (rhs1_type) != VECTOR_TYPE > > || TREE_CODE (rhs2_type) != VECTOR_TYPE > > || TREE_CODE (rhs3_type) != VECTOR_TYPE) > > { > > @@ -4330,10 +4326,29 @@ verify_gimple_assign_ternary (gassign *stmt) > > return true; > > } > > > > + /* If lhs, rhs1, and rhs2 are different vector types, > > + then relax the check if rhs3 is constant and lhs, rhs1, and rhs2 > > + have same element types. */ > > + if ((!useless_type_conversion_p (lhs_type, rhs1_type) > > + || !useless_type_conversion_p (lhs_type, rhs2_type)) > > + && (!TREE_CONSTANT (rhs3) > > + || TREE_TYPE (lhs_type) != TREE_TYPE (rhs1_type) > > + || TREE_TYPE (lhs_type) != TREE_TYPE (rhs2_type))) > > These TREE_TYPE tests should use !useless_type_conversion_p too, > instead of !=. Maybe it would be easier to follow as: > > if (TREE_CONSTANT (rhs3) > ? ... > : ...) > > so that we don't have doubled useless_type_conversion_p checks > for the TREE_CONSTANT case. > > > + { > > + error ("type mismatch in %qs", code_name); > > + debug_generic_expr (lhs_type); > > + debug_generic_expr (rhs1_type); > > + debug_generic_expr (rhs2_type); > > + debug_generic_expr (rhs3_type); > > + return true; > > + } > > + > > + /* If rhs3 is constant, relax the check len(rhs2) == len(rhs3). */ > > if (maybe_ne (TYPE_VECTOR_SUBPARTS (rhs1_type), > > TYPE_VECTOR_SUBPARTS (rhs2_type)) > > - || maybe_ne (TYPE_VECTOR_SUBPARTS (rhs2_type), > > + || (maybe_ne (TYPE_VECTOR_SUBPARTS (rhs2_type), > > TYPE_VECTOR_SUBPARTS (rhs3_type)) > > + && !TREE_CONSTANT (rhs3)) > > Very minor, but I think this reads better with the !TREE_CONSTANT first > in the && rather than second. There's no reason to compare the lengths > for TREE_CONSTANT. > > Otherwise it looks good to me, but Richard should have the final say. Thanks, I addressed the above suggestions in the attached patch. Does it look OK ? Thanks, Prathamesh > > Thanks, > Richard > > > || maybe_ne (TYPE_VECTOR_SUBPARTS (rhs3_type), > > TYPE_VECTOR_SUBPARTS (lhs_type))) > > {