From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 36BEE388E80E for ; Mon, 9 May 2022 13:52:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 36BEE388E80E Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D1D9B1480; Mon, 9 May 2022 06:52:18 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 35BE63F73D; Mon, 9 May 2022 06:52:18 -0700 (PDT) From: Richard Sandiford To: Prathamesh Kulkarni Mail-Followup-To: Prathamesh Kulkarni , Richard Biener , gcc Patches , richard.sandiford@arm.com Cc: Richard Biener , gcc Patches Subject: Re: [2/2] PR96463 -- changes to type checking vec_perm_expr in middle end References: <72p4o95q-697o-1o21-po9r-58r6rq3nq9n@fhfr.qr> <627013s-9227-o1rp-12p-sr4sp6rn897p@fhfr.qr> Date: Mon, 09 May 2022 14:52:16 +0100 In-Reply-To: (Prathamesh Kulkarni's message of "Mon, 9 May 2022 16:51:47 +0530") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2022 13:52:21 -0000 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_per= m_expr >> >> >> >> > and relaxes type checking for >> >> >> >> > lhs =3D vec_perm_expr >> >> >> >> > >> >> >> >> > when: >> >> >> >> > rhs1 =3D=3D rhs2, >> >> >> >> > lhs is variable length vector, >> >> >> >> > rhs1 is fixed length vector, >> >> >> >> > TREE_TYPE (lhs) =3D=3D 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 vect= or to >> >> >> >> > it's VLA equivalent. >> >> >> >> >> >> >> >> VLAness isn't really the issue. We want the same thing to work= for >> >> >> >> -msve-vector-bits=3D256, -msve-vector-bits=3D512, etc., even th= ough the >> >> >> >> vectors are fixed-length in that case. >> >> >> >> >> >> >> >> The principle is that for: >> >> >> >> >> >> >> >> A =3D 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 elemen= ts of B >> >> >> >> followed by all element of C) and that: >> >> >> >> >> >> >> >> A[i] =3D BC[D[i] % (NB+NB)] >> >> >> >> >> >> >> >> for 0 =E2=89=A4 i < NA. >> >> >> >> >> >> >> >> This operation makes sense even if NA !=3D NB. >> >> >> > >> >> >> > But note that we don't currently expect NA !=3D NB and the optab= just >> >> >> > has a single mode. >> >> >> >> >> >> True, but we only need this for constant permutes. They are alrea= dy >> >> >> 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 r= elax >> >> > 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 t= he >> >> patch would need to wait for GCC 13 whatever happens. >> > Hi, >> > In attached patch, the type checking is relaxed only if mask is consta= nt. >> > 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) =3D=3D len(rhs3) && len(rhs1) =3D=3D 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) =3D=3D TREE_TYPE (rhs1_type) >> > + && TREE_TYPE (lhs_type) =3D=3D TREE_TYPE (rhs2_type) >> > + && INTEGRAL_TYPE_P (TREE_TYPE (rhs3_type)) >> > + && known_eq (TYPE_VECTOR_SUBPARTS (lhs_type), TYPE_VECTOR_SUBP= ARTS (rhs3_type)) >> > + && known_eq (TYPE_VECTOR_SUBPARTS (rhs1_type), TYPE_VECTOR_SUB= PARTS (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) !=3D VECTOR_TYPE >> || TREE_CODE (rhs2_type) !=3D VECTOR_TYPE >> || TREE_CODE (rhs3_type) !=3D 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 =3D=3D. > 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; >=20=20 > 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) =3D=3D len(rhs3) && len(rhs1) =3D=3D len(rhs2). */ >=20=20 > - if (TREE_CODE (rhs1_type) !=3D VECTOR_TYPE > + if (TREE_CODE (lhs_type) !=3D VECTOR_TYPE > + || TREE_CODE (rhs1_type) !=3D VECTOR_TYPE > || TREE_CODE (rhs2_type) !=3D VECTOR_TYPE > || TREE_CODE (rhs3_type) !=3D VECTOR_TYPE) > { > @@ -4330,10 +4326,29 @@ verify_gimple_assign_ternary (gassign *stmt) > return true; > } >=20=20 > + /* 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) !=3D TREE_TYPE (rhs1_type) > + || TREE_TYPE (lhs_type) !=3D TREE_TYPE (rhs2_type))) These TREE_TYPE tests should use !useless_type_conversion_p too, instead of !=3D. 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) =3D=3D 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, Richard > || maybe_ne (TYPE_VECTOR_SUBPARTS (rhs3_type), > TYPE_VECTOR_SUBPARTS (lhs_type))) > {