From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130889 invoked by alias); 7 Oct 2019 13:51:09 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 130880 invoked by uid 89); 7 Oct 2019 13:51:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=presented, scanning, HX-Languages-Length:3106 X-HELO: esa2.mentor.iphmx.com Received: from esa2.mentor.iphmx.com (HELO esa2.mentor.iphmx.com) (68.232.141.98) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 07 Oct 2019 13:51:07 +0000 IronPort-SDR: 3Vgl0TAGVqyq5AdZzddVRD5yzWVSAsu2LaxanDT/cN2L4khoUEgOLlhLZD/G4DXfltDV8Vwaux Aog2XmzHR1jUOG5Njc1RVPCAHVRNnBDK58GRD54tRA3gZkMOqczOFd6VcTcHqIRqzkU+drBHlc izLV252JB0sZkazlbcpQgPN3g/hVsngqRMrQVuptEvcX81vVro07Nikz3E06j92ZczdbtoxhyI ++4HDEX4w2251J2RgnWi3VMBppS9GXluhMNhXhRWtvioeLmSH7JoEdt5tRIKtlpQf1qARpScc6 +Qg= Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 07 Oct 2019 05:51:05 -0800 IronPort-SDR: ljeM/9VHUTdL3ZM2t0NPoCRIt42w6B39aVOXwEbvMgNn71bFzCQx+CQMknRDFIGA0a5gVqb4+T AKJYGKDxvODyFCegH9MGpXS4WexgyIxqO2tEfaO9KtpYRsg01gbiit8SlTkBT6pD9VLrLTcGP+ SDbqIMDuCC4D64oWSwSwiKGYnWdZ8gdLyJztdAxG8z5LMmTh/o1sKLKemZO52wL1EJvU33uuQg 8w7q8QlLXdgO4k7etbs122WngYwybmMfCfcsIvyFtbRXmXYRNp/USwTDAKxeoFZ2GL52jCNtqW 6AQ= From: Thomas Schwinge To: CC: gcc-patches , Jakub Jelinek Subject: Re: [PATCH, OpenACC, 1/3] Non-contiguous array support for OpenACC data clauses (re-submission), front-end patches In-Reply-To: References: User-Agent: Notmuch/0.29.1+93~g67ed7df (https://notmuchmail.org) Emacs/26.1 (x86_64-pc-linux-gnu) Date: Mon, 07 Oct 2019 13:51:00 -0000 Message-ID: <87v9t01x6x.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-Path: tschwing@mentor.com X-SW-Source: 2019-10/txt/msg00470.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 3239 Hi Chung-Lin! Thanks for your work on this. Please reference PR76739 in your submission/ChangeLog updates. We'll need Jakub to review the generic code changes, but let me provide some first review remarks, too. On 2019-08-20T19:36:24+0800, Chung-Lin Tang wrot= e: > The first patch here are the C/C++ front-end patches. As far as I'm concerned, it doesn't make sense to artificially split up patches like that, given that the individual three pieces can only be considered all together. And if posting split-up for other reasonse, then please make sure that the individual patch submission emails have a common "cover letter" email so that they show up as one email thread. > --- gcc/c/c-typeck.c (revision 274618) > +++ gcc/c/c-typeck.c (working copy) > @@ -13099,6 +13100,21 @@ handle_omp_array_sections_1 (tree c, tree t, vec= } > } > } > + > + /* For OpenACC, if the low_bound/length suggest this is a subarray, > + and is referenced through by a pointer, then mark this as > + non-contiguous. */ I don't directly understand this logic. I'll have to think about it more. > + if (ort =3D=3D C_ORT_ACC > + && types.length () > 0 > + && (TREE_CODE (low_bound) !=3D INTEGER_CST > + || integer_nonzerop (low_bound) > + || (length && (TREE_CODE (length) !=3D INTEGER_CST > + || !tree_int_cst_equal (size, length))))) > + { > + tree x =3D types.last (); > + if (TREE_CODE (x) =3D=3D POINTER_TYPE) > + non_contiguous =3D true; > + } > } > else if (length =3D=3D NULL_TREE) > { > @@ -13142,7 +13158,8 @@ handle_omp_array_sections_1 (tree c, tree t, vec /* If there is a pointer type anywhere but in the very first > array-section-subscript, the array section can't be contiguous. */ > if (OMP_CLAUSE_CODE (c) !=3D OMP_CLAUSE_DEPEND > - && TREE_CODE (TREE_CHAIN (t)) =3D=3D TREE_LIST) > + && TREE_CODE (TREE_CHAIN (t)) =3D=3D TREE_LIST > + && ort !=3D C_ORT_ACC) > { > error_at (OMP_CLAUSE_LOCATION (c), > "array section is not contiguous in %qs clause", > @@ -13149,6 +13166,8 @@ handle_omp_array_sections_1 (tree c, tree t, vec omp_clause_code_name[OMP_CLAUSE_CODE (c)]); > return error_mark_node; > } > + else if (TREE_CODE (TREE_CHAIN (t)) =3D=3D TREE_LIST) > + non_contiguous =3D true; > } > else > { > @@ -13337,6 +13365,14 @@ handle_omp_array_sections (tree c, enum c_omp_re= gi > size =3D size_binop (MULT_EXPR, size, l); > } > } > + if (non_contiguous) > + { > + int kind =3D OMP_CLAUSE_MAP_KIND (c); > + OMP_CLAUSE_SET_MAP_KIND (c, kind | GOMP_MAP_NONCONTIG_ARRAY); > + OMP_CLAUSE_DECL (c) =3D t; > + OMP_CLAUSE_SIZE (c) =3D ncarray_dims; > + return false; > + } I'm expecting to see front end test cases (probably '-fdump-tree-original' scanning?) for a good number of different data clauses/array variants, whether that flag 'GOMP_MAP_NONCONTIG_ARRAY' has been set or not. (That would then also document the logic presented above, and should thus help me understand that.) > --- gcc/cp/semantics.c (revision 274618) > +++ gcc/cp/semantics.c (working copy) Likewise. Gr=C3=BC=C3=9Fe Thomas --=-=-= Content-Type: application/pgp-signature; name="signature.asc" Content-length: 658 -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEEU9WEfWKGQazCmycCAKI7+41Q4XkFAl2bQrYACgkQAKI7+41Q 4Xm2bgv/YoRPFg4Q6BfhPpdfiohcOhYhFAmR01iXvARTJZf+XgWBFMbEEvG63Nzj bQlXNxrtxwoHLxS85xDkjkVrI6WDasxAX2TYEqWjBJn7za+173+ugigziDka1a5s 3F4+nnLxZgILM+Xre1J1x4rRypIKIVUfn1oWYIS/KffCwMIG8BE0zJX6S35J02wC xIRuFkQ2SXHkYdZ6q8yPvru8qJpsIrrNMYGeu9wjCCpsWEDsMqkw822rBEH0HDVH Z1nClG/CX1O3cdJFjFZ2mxfHQA1O/QIeGZdhmgAxJ/yPw5xjhIa4+yluOOzgmo8w sjRJ2TJYMszXLPIiHxMaQrXcOsDfXb4le0jGXxvIwsoh0tISmyZiM5fzUaEB2k+4 Qss18amT6NWQ3vgKRcPPkCmzYHfdeyXZDdf9vfYImYbg4z/UuBf7zLheXNaQiVaF yZzprDwk9h6PvjFXWCE6TItRn/+Pyx21IpAaUXh/8WB6wdm2Lw5BhqcllL8uYB32 k0Z6Y2Bo =zeTo -----END PGP SIGNATURE----- --=-=-=--