From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 792923858D32 for ; Mon, 23 May 2022 17:28:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 792923858D32 Received: by mail-ej1-x629.google.com with SMTP id q21so10102109ejm.1 for ; Mon, 23 May 2022 10:28:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=Fj6yOGKaODu/ONtRTiWReblYpMpnVMDCkJsPafRaA48=; b=emN0SAiHAQItYcKZeEZXLVqrgLHSGFsKEMmo58jPNRbGFtBq4ImuNqWUqlhCIuHN3a ug8or8Zhpoqikx0sQS6iebz+3qJ6nEWL5l/0GT+ezAIvySvc0uuJIRnL/66f+4Yu6I08 8+sHZVaxCZst6abr1H5xD0TSZNt1Qw79V0XdklFLw3hu5ZhV8LYC5fwK2wdyVotEnDLk MSUGydytwy1Qherx932YRDdyHmCz5l4lhdvTqDdH16+Ba/yaxf24hP5ajzFKk5q1io1b YHR66mXv5zwFjjLKiAwjpD+3V+Ya/9RqLfvbRhf+r2du4U9TmYa23Ytf0hgCmq+mpvzh n5mg== X-Gm-Message-State: AOAM531C0b+fpZ+ulm0+P4+SzvrJkrZxihzUPOFTrxhIhjwZ7WicQd1F TktbNxjfbzKRHv06NczFWColQzh4+q+WXRZZV6Fq7A== X-Google-Smtp-Source: ABdhPJxohWOJFv0/LSEomLdv5TjbtQDG9HXqLpDPV5JsmFPOXoWVvXJyl3ZvUZde7jgOAteAFO8ucYEl7gt9s4jQ3mk= X-Received: by 2002:a17:907:6e88:b0:6fa:888d:74a7 with SMTP id sh8-20020a1709076e8800b006fa888d74a7mr20404066ejc.335.1653326905900; Mon, 23 May 2022 10:28:25 -0700 (PDT) MIME-Version: 1.0 References: <72p4o95q-697o-1o21-po9r-58r6rq3nq9n@fhfr.qr> <627013s-9227-o1rp-12p-sr4sp6rn897p@fhfr.qr> In-Reply-To: From: Prathamesh Kulkarni Date: Mon, 23 May 2022 22:57:49 +0530 Message-ID: Subject: Re: [2/2] PR96463 -- changes to type checking vec_perm_expr in middle end To: Prathamesh Kulkarni , Richard Biener , gcc Patches , richard.sandiford@arm.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 23 May 2022 17:28:30 -0000 On Mon, 9 May 2022 at 21:21, Prathamesh Kulkarni wrote: > > 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 =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 wa= s 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=3D256, -msve-vector-bits=3D512, etc., eve= n though 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 el= ements 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 o= ptab just > > >> >> >> > has a single mode. > > >> >> >> > > >> >> >> True, but we only need this for constant permutes. They are a= lready > > >> >> >> 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 on= ly 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 opera= nds > > >> >> 1 and 2. Maybe that was just an oversight, or maybe it seemed ob= vious > > >> >> or self-explanatory at the time. :-) > > >> >> > > >> >> > As said I prefer to not mangle the existing stmt checking too m= uch > > >> >> > at this stage so minimal adjustment is prefered there. > > >> >> > > >> >> The PR is only an enhancement request rather than a bug, so I thi= nk the > > >> >> patch would need to wait for GCC 13 whatever happens. > > >> > Hi, > > >> > In attached patch, the type checking is relaxed only if mask is co= nstant. > > >> > 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_= 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) !=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 t= o > > > 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) =3D=3D len(rhs3) && len(rhs1) =3D=3D len(rhs2). = */ > > > > > > - 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; > > > } > > > > > > + /* If lhs, rhs1, and rhs2 are different vector types, > > > + then relax the check if rhs3 is constant and lhs, rhs1, and rh= s2 > > > + 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(r= hs3). */ > > > 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 ? ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594349.html Patch passes bootstrap+test on x86_64-linux-gnu. On aarch64-linux-gnu, the patch passes bootstrap, but I am seeing these discrepancies in test results: New tests that FAIL (2 tests): g++.dg/modules/macloc-1_c.C -std=3Dc++17 dg-regexp 13 not found: "[^\\n]*macloc-1_c.C:8:7: error: too many arguments to function 'int you@agnes\\(\\)'\\nIn module agnes, imported at [^\\n]*macloc-1_b.C:8,\\nof module edith, imported at [^\\n]*macloc-1_c.C:3:\\n[^\\n]*macloc-1_a.C:12:14: note: declared here\\n[^\\n]*macloc-1_a.C:9:22: note: in definition of macro 'KEVIN'\\n" g++.dg/modules/macloc-1_c.C -std=3Dc++17 (test for excess errors) Old tests that failed, that have disappeared (2 tests): (Eeek!) c-c++-common/missing-header-3.c -Wc++-compat expected multiline pattern lines 5-7 not found: "\\s*#import [^\\n\\r]*\\n \\^~~~~~~~~~~~~~~~~~~~~~~~~~~~\\ncompilation terminated\\.[^\\n\\r]*\\n" c-c++-common/missing-header-3.c -Wc++-compat (test for excess errors) I am not sure if these seem related to patch tho ? Thanks, Prathamesh > > Thanks, > Prathamesh > > > > Thanks, > > Richard > > > > > || maybe_ne (TYPE_VECTOR_SUBPARTS (rhs3_type), > > > TYPE_VECTOR_SUBPARTS (lhs_type))) > > > {