From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104322 invoked by alias); 19 Oct 2015 10:20:38 -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 104305 invoked by uid 89); 19 Oct 2015 10:20:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Oct 2015 10:20:35 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1Zo7YN-0002kU-Ve from Thomas_Schwinge@mentor.com ; Mon, 19 Oct 2015 03:20:32 -0700 Received: from feldtkeller.schwinge.homeip.net (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Mon, 19 Oct 2015 11:20:30 +0100 From: Thomas Schwinge To: Jakub Jelinek CC: , Kirill Yukhin , Ilya Verbin Subject: Re: [gomp4.1] map clause parsing improvements In-Reply-To: <20150611121420.GY10247@tucnak.redhat.com> References: <20150429111406.GE1751@tucnak.redhat.com> <874mnzrw1z.fsf@schwinge.name> <20150429120644.GG1751@tucnak.redhat.com> <20150609183608.GA47936@msticlxl57.ims.intel.com> <20150611121420.GY10247@tucnak.redhat.com> User-Agent: Notmuch/0.9-125-g4686d11 (http://notmuchmail.org) Emacs/24.5.1 (i586-pc-linux-gnu) Date: Mon, 19 Oct 2015 10:34:00 -0000 Message-ID: <87zizf9n2w.fsf@kepler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-SW-Source: 2015-10/txt/msg01713.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 4031 Hi! On Thu, 11 Jun 2015 14:14:20 +0200, Jakub Jelinek wrote: > On Tue, Jun 09, 2015 at 09:36:08PM +0300, Ilya Verbin wrote: > > On Wed, Apr 29, 2015 at 14:06:44 +0200, Jakub Jelinek wrote: > > > [...] The draft requires only alloc or to > > > (or always, variants) for enter data and only from or delete (or alwa= ys, > > > variants) for exit data, so in theory it is possible to figure that f= rom > > > the call without extra args, but not so for update - enter data is su= pposed > > > to increment reference counts, exit data decrement. [...] > >=20 > > TR3.pdf also says about 'release' map-type for exit data, but it is not > > described in the document. >=20 > So, I've committed a patch to add parsing release map-kind, and fix up or= add > verification in C/C++ FE what map-kinds are used. >=20 > Furthermore, it seems the OpenMP 4.1 always modifier is something complet= ely > unrelated to the OpenACC force flag, in OpenMP 4.1 everything is reference > count based, and always seems to make a difference only for from/to/tofro= m, > where it says that the copying is done unconditionally; thus the patch us= es > a different bit for that. Aha, I see. (The poor OpenACC/OpenMP users, having to remember so may small yet intricate details...) > include/ > * gomp-constants.h (GOMP_MAP_FLAG_ALWAYS): Define. > (enum gomp_map_kind): Add GOMP_MAP_ALWAYS_TO, GOMP_MAP_ALWAYS_FROM, > GOMP_MAP_ALWAYS_TOFROM, GOMP_MAP_DELETE, GOMP_MAP_RELEASE. > --- include/gomp-constants.h.jj 2015-05-21 11:12:09.000000000 +0200 > +++ include/gomp-constants.h 2015-06-11 11:24:32.041654947 +0200 > @@ -41,6 +41,8 @@ > #define GOMP_MAP_FLAG_SPECIAL_1 (1 << 3) > #define GOMP_MAP_FLAG_SPECIAL (GOMP_MAP_FLAG_SPECIAL_1 \ > | GOMP_MAP_FLAG_SPECIAL_0) > +/* OpenMP always flag. */ > +#define GOMP_MAP_FLAG_ALWAYS (1 << 6) > /* Flag to force a specific behavior (or else, trigger a run-time error)= . */ > #define GOMP_MAP_FLAG_FORCE (1 << 7) >=20=20 > @@ -77,7 +79,21 @@ enum gomp_map_kind > /* ..., and copy from device. */ > GOMP_MAP_FORCE_FROM =3D (GOMP_MAP_FLAG_FORCE | GOMP_MAP_FROM), > /* ..., and copy to and from device. */ > - GOMP_MAP_FORCE_TOFROM =3D (GOMP_MAP_FLAG_FORCE | GOMP_MAP_TOFROM) > + GOMP_MAP_FORCE_TOFROM =3D (GOMP_MAP_FLAG_FORCE | GOMP_MAP_TOFROM), > + /* If not already present, allocate. And unconditionally copy to > + device. */ > + GOMP_MAP_ALWAYS_TO =3D (GOMP_MAP_FLAG_ALWAYS | GOMP_MAP_TO), > + /* If not already present, allocate. And unconditionally copy from > + device. */ > + GOMP_MAP_ALWAYS_FROM =3D (GOMP_MAP_FLAG_ALWAYS | GOMP_MAP_FROM), > + /* If not already present, allocate. And unconditionally copy to an= d from > + device. */ > + GOMP_MAP_ALWAYS_TOFROM =3D (GOMP_MAP_FLAG_ALWAYS | GOMP_MAP_TOFROM), > + /* OpenMP 4.1 alias for forced deallocation. */ > + GOMP_MAP_DELETE =3D GOMP_MAP_FORCE_DEALLOC, To avoid confusion about two different identifiers naming the same functionality, I'd prefer to avoid such aliases ("GOMP_MAP_DELETE =3D GOMP_MAP_FORCE_DEALLOC"), and instead just rename GOMP_MAP_FORCE_DEALLOC to GOMP_MAP_DELETE, if that's the name you prefer. By the way, looking at GCC 6 libgomp compatibility regarding OpenACC/nvptx offloading for executables compiled with GCC 5, for the legacy entry point libgomp/oacc-parallel.c:GOACC_parallel only supports host-fallback execution, which doesn't pay attention to data clause at all (sizes and kinds formal parameters), so you're free to renumber GOMP_MAP_* if/where that makes sense. > + /* Decrement usage count and deallocate if zero. */ > + GOMP_MAP_RELEASE =3D (GOMP_MAP_FLAG_ALWAYS > + | GOMP_MAP_FORCE_DEALLOC) > }; I have not yet read the OpenMP 4.1/4.5 standard, but it's not obvious to me here how the GOMP_MAP_FLAG_ALWAYS flag relates to the OpenMP release clause (GOMP_MAP_RELEASE here)? Shouldn't GOMP_MAP_RELEASE be "(GOMP_MAP_FLAG_SPECIAL_1 | 3)" or similar? Gr=C3=BC=C3=9Fe Thomas --=-=-= Content-Type: application/pgp-signature; name="signature.asc" Content-length: 472 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWJMPnAAoJEK3/DN1sMFFtcxkH/2K2eHmGc5+qbRtv1d06lrKS uIAsi0k5AOL2sxVsznFYib9y0glFGkdN4qt7/ZFWdjF/5hU8dLxET6Goq5+3CTEt eTTkXRPMk+naClKJafzwR/nhnIgiCd7whqN1DY2dmG9obGEtjF/CfMwmKnYqsbnP d5Rs9+qSm5799mQaoAjhxfq2eRXbdTVpKvLAdfVoogGHN3L5Zx6XFb9PsLf2Plaf 0B3eOK+5kBaK/Bw3ThSjSo5C8TMFW2cHfpdI3n/dv11KylQnlTkVm3O1yDTbP9gu b+wskUMBwuMVuptiTIhISAjdGb/KemacXgzq44w9e8f5EU9oUeUG6tMHlrFVIBk= =3XrO -----END PGP SIGNATURE----- --=-=-=--