From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20013 invoked by alias); 19 Oct 2015 10:34:17 -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 19998 invoked by uid 89); 19 Oct 2015 10:34:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 19 Oct 2015 10:34:15 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id EEFF7AE5C4; Mon, 19 Oct 2015 10:34:13 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-53.ams2.redhat.com [10.36.116.53]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9JAYCkm030646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Oct 2015 06:34:13 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id t9JAYAw6026389; Mon, 19 Oct 2015 12:34:11 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id t9JAY8TF026388; Mon, 19 Oct 2015 12:34:08 +0200 Date: Mon, 19 Oct 2015 10:46:00 -0000 From: Jakub Jelinek To: Thomas Schwinge Cc: gcc-patches@gcc.gnu.org, Kirill Yukhin , Ilya Verbin Subject: Re: [gomp4.1] map clause parsing improvements Message-ID: <20151019103408.GP478@tucnak.redhat.com> Reply-To: Jakub Jelinek 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zizf9n2w.fsf@kepler.schwinge.homeip.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg01714.txt.bz2 On Mon, Oct 19, 2015 at 12:20:23PM +0200, Thomas Schwinge wrote: > > @@ -77,7 +79,21 @@ enum gomp_map_kind > > /* ..., and copy from device. */ > > GOMP_MAP_FORCE_FROM = (GOMP_MAP_FLAG_FORCE | GOMP_MAP_FROM), > > /* ..., and copy to and from device. */ > > - GOMP_MAP_FORCE_TOFROM = (GOMP_MAP_FLAG_FORCE | GOMP_MAP_TOFROM) > > + GOMP_MAP_FORCE_TOFROM = (GOMP_MAP_FLAG_FORCE | GOMP_MAP_TOFROM), > > + /* If not already present, allocate. And unconditionally copy to > > + device. */ > > + GOMP_MAP_ALWAYS_TO = (GOMP_MAP_FLAG_ALWAYS | GOMP_MAP_TO), > > + /* If not already present, allocate. And unconditionally copy from > > + device. */ > > + GOMP_MAP_ALWAYS_FROM = (GOMP_MAP_FLAG_ALWAYS | GOMP_MAP_FROM), > > + /* If not already present, allocate. And unconditionally copy to and from > > + device. */ > > + GOMP_MAP_ALWAYS_TOFROM = (GOMP_MAP_FLAG_ALWAYS | GOMP_MAP_TOFROM), > > + /* OpenMP 4.1 alias for forced deallocation. */ > > + GOMP_MAP_DELETE = 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 = > GOMP_MAP_FORCE_DEALLOC"), and instead just rename GOMP_MAP_FORCE_DEALLOC > to GOMP_MAP_DELETE, if that's the name you prefer. If you are ok with removing GOMP_MAP_FORCE_DEALLOC and just use GOMP_MAP_DELETE, that is ok by me, just post a patch. > 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 = (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? 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 that 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. Some changes in the enum can be of course still be done until say mid stage3 but at least for OpenMP 4.0 we should keep backwards compatibility (so whatever we've already used in GCC 4.9/5 should keep working). Jakub