From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95614 invoked by alias); 19 Oct 2015 15:01:05 -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 94757 invoked by uid 89); 19 Oct 2015 15:01:04 -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 15:00:59 +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 1ZoBvj-0001q5-A1 from Thomas_Schwinge@mentor.com ; Mon, 19 Oct 2015 08:00:55 -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 16:00:54 +0100 From: Thomas Schwinge To: Jakub Jelinek CC: , Kirill Yukhin , Ilya Verbin Subject: Re: [gomp4.1] map clause parsing improvements In-Reply-To: <20151019103408.GP478@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> <87zizf9n2w.fsf@kepler.schwinge.homeip.net> <20151019103408.GP478@tucnak.redhat.com> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 19 Oct 2015 15:14:00 -0000 Message-ID: <87vba29a3y.fsf@schwinge.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-SW-Source: 2015-10/txt/msg01758.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 3326 Hi! On Mon, 19 Oct 2015 12:34:08 +0200, Jakub Jelinek wrote: > On Mon, Oct 19, 2015 at 12:20:23PM +0200, Thomas Schwinge wrote: > > > + /* Decrement usage count and deallocate if zero. */ > > > + GOMP_MAP_RELEASE =3D (GOMP_MAP_FLAG_ALWAYS > > > + | GOMP_MAP_FORCE_DEALLOC) > > > }; > >=20 > > 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? >=20 > It isn't related to always, but always really is something that affects > solely the data movement (i.e. to, from, tofrom), and while it can be > specified elsewhere, it makes no difference. Wasting one bit just for th= at > is something we don't have the luxury for, which is why I've started using > that bit for other OpenMP stuff (it acts there like GOMP_MAP_FLAG_SPECIAL= _2 > to some extent). It is not just release, but also the struct mapping etc. > I'll still need to make further changes, because the rules for mapping > structure element pointer/reference based array sections and structure > element references have changed again. Hmm, I do think we should allow the luxury to use its own bit for GOMP_MAP_FLAG_ALWAYS -- we can extend the interface later, should we really find uses for the other two remaining bits -- or if not using a separate bit, at least make sure that GOMP_MAP_FLAG_ALWAYS is not used as a flag. See, for example, the following occasions where GOMP_MAP_FLAG_ALWAYS is used as a flag: these conditionals will also be matched for GOMP_MAP_STRUCT, GOMP_MAP_DELETE_ZERO_LEN_ARRAY_SECTION, and GOMP_MAP_RELEASE. I have not analyzed whether that is erroneous or not, but it surely is confusing? $ < gcc/gimplify.c grep -C3 GOMP_MAP_FLAG_ALWAYS struct_map_to_clause->put (decl, *list_p); list_p =3D &OMP_CLAUSE_CHAIN (*list_p); flags =3D GOVD_MAP | GOVD_EXPLICIT; if (OMP_CLAUSE_MAP_KIND (c) & GOMP_MAP_FLAG_ALWAY= S) flags |=3D GOVD_SEEN; goto do_add_decl; } -- tree *sc =3D NULL, *pt =3D NULL; if (!ptr && TREE_CODE (*osc) =3D=3D TREE_LIST) osc =3D &TREE_PURPOSE (*osc); if (OMP_CLAUSE_MAP_KIND (c) & GOMP_MAP_FLAG_ALWAY= S) n->value |=3D GOVD_SEEN; offset_int o1, o2; if (offset) -- n =3D splay_tree_lookup (ctx->variables, (splay_tree_key) dec= l); if ((ctx->region_type & ORT_TARGET) !=3D 0 && !(n->value & GOVD_SEEN) && ((OMP_CLAUSE_MAP_KIND (c) & GOMP_MAP_FLAG_ALWAYS) =3D= =3D 0 || OMP_CLAUSE_MAP_KIND (c) =3D=3D GOMP_MAP_STRUCT)) { remove =3D true; I'd suggest turning GOMP_MAP_FLAG_ALWAYS into GOMP_MAP_FLAG_SPECIAL_2, and then provide a GOMP_MAP_ALWAYS_P that evaluates to true just for the three "always,to", "always,from", and "always,tofrom" cases. Gr=C3=BC=C3=9Fe, Thomas --=-=-= Content-Type: application/pgp-signature; name="signature.asc" Content-length: 472 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWJQWRAAoJEPoxNhtoi6COwyYH/2cpw39kS9/r4oS9wvch4zg1 5lf64YAFSlJscPQy4c0HpEH/ByJYdC9+cEoOnsYmtb7bd6STBKFCEZh0Vzd25Wuk t4TYI2p4Dt/jEymenEsSbU89vXayYh2+KsXm01L7g1fwdk19ZF8fgfiXaz08Kc3a X0H32W57HkyewxJyu5lkKE6Eg4rXk/yjpiSWSNld40J0CagpztARLvA38dzcyT5F ig6wU23GdDNu1rgNsS0Glm54pqCg2FTivUV2dwIkyk4rMuy8NkwbHYjKsZYucsHb VF+Jbjw5+f7rEGcdHSKmwIOYkzYHft6l5WstaFYQ6TLOpV8BOhDfWQb8lMTkQ0g= =0vVY -----END PGP SIGNATURE----- --=-=-=--