From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71304 invoked by alias); 29 Apr 2015 12:06:56 -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 71294 invoked by uid 89); 29 Apr 2015 12:06:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD 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; Wed, 29 Apr 2015 12:06:54 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3TC6o11030462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 29 Apr 2015 08:06:51 -0400 Received: from tucnak.zalov.cz (ovpn-116-89.ams2.redhat.com [10.36.116.89]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3TC6nNl021079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Apr 2015 08:06:50 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t3TC6lQL017456; Wed, 29 Apr 2015 14:06:47 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t3TC6iHE017455; Wed, 29 Apr 2015 14:06:44 +0200 Date: Wed, 29 Apr 2015 12:31:00 -0000 From: Jakub Jelinek To: Thomas Schwinge Cc: gcc-patches@gcc.gnu.org, Kirill Yukhin , Richard Henderson Subject: Re: [gomp4.1] Initial support for some OpenMP 4.1 construct parsing Message-ID: <20150429120644.GG1751@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20150429111406.GE1751@tucnak.redhat.com> <874mnzrw1z.fsf@schwinge.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874mnzrw1z.fsf@schwinge.name> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg01867.txt.bz2 On Wed, Apr 29, 2015 at 01:52:24PM +0200, Thomas Schwinge wrote: > Hi Jakub! > > (I have not yet read any version of the OpenMP 4.1 standard.) There is no OpenMP 4.1 standard, just the public TR3 released in November last year, and then some non-public WIP. > > + tree stmt = make_node (OMP_TARGET_DATA); > > + TREE_TYPE (stmt) = void_type_node; > > + OMP_TARGET_DATA_CLAUSES (stmt) = clauses; > > Even if it doesn't make a lot of sense, my reading of OpenMP 4.0 has been > that a target data construct without any map clauses is still valid. > (But I have not verified that now.) Yes, it is valid in OpenMP 4.0. But in GCC we're just supporting the latest standard, there is no -fopenmp={2.5,3.0,3.1,4.0,4.1} like there is -std=c{89,99,11}. > > --- gcc/omp-low.c.jj 2015-04-29 10:58:01.489748182 +0200 > > +++ gcc/omp-low.c 2015-04-29 11:03:04.646991017 +0200 > > @@ -8994,6 +9017,11 @@ expand_omp_target (struct omp_region *re > > case GF_OMP_TARGET_KIND_UPDATE: > > start_ix = BUILT_IN_GOMP_TARGET_UPDATE; > > break; > > + case GF_OMP_TARGET_KIND_ENTER_DATA: > > + case GF_OMP_TARGET_KIND_EXIT_DATA: > > + /* FIXME */ > > + start_ix = BUILT_IN_GOMP_TARGET_UPDATE; > > + break; > > Actually, I've also wondered (but never verified) whether all of the > OpenACC enter, exit, and update constructs can be implemented via the > same libgomp API. Well, the behavior is different. The draft requires only alloc or to (or always, variants) for enter data and only from or delete (or always, variants) for exit data, so in theory it is possible to figure that from the call without extra args, but not so for update - enter data is supposed to increment reference counts, exit data decrement. And, we'll need new arguments for async (pass through info that it is async (nowait) or sync, and the depend clause address(es)). > > > @@ -11488,6 +11520,9 @@ lower_omp_target (gimple_stmt_iterator * > > default: > > gcc_unreachable (); > > } > > + /* FIXME: Temporary hack. */ > > + if (talign_shift == 3) > > + tkind &= ~GOMP_MAP_FLAG_FORCE; > > gcc_checking_assert (tkind > > < (HOST_WIDE_INT_C (1U) << talign_shift)); > > talign = ceil_log2 (talign); > > Assuming you'll be changing the relevant functions' APIs, and assigning > new ABI versions, don't forget to also drop the unused offload_table > formal parameter (assuming that it remains unused). Yeah, we'll need new GOMP_target{,_data,_end_data,_update} replacements. > > --- gcc/tree-pretty-print.c.jj 2015-04-29 10:58:01.663745452 +0200 > > +++ gcc/tree-pretty-print.c 2015-04-29 11:03:04.648990986 +0200 > > @@ -550,22 +560,22 @@ dump_omp_clause (pretty_printer *pp, tre > > pp_string (pp, "tofrom"); > > break; > > case GOMP_MAP_FORCE_ALLOC: > > - pp_string (pp, "force_alloc"); > > + pp_string (pp, "always,alloc"); > > break; > > case GOMP_MAP_FORCE_TO: > > - pp_string (pp, "force_to"); > > + pp_string (pp, "always,to"); > > break; > > case GOMP_MAP_FORCE_FROM: > > - pp_string (pp, "force_from"); > > + pp_string (pp, "always,from"); > > break; > > case GOMP_MAP_FORCE_TOFROM: > > - pp_string (pp, "force_tofrom"); > > + pp_string (pp, "always,tofrom"); > > break; > > case GOMP_MAP_FORCE_PRESENT: > > pp_string (pp, "force_present"); > > break; > > case GOMP_MAP_FORCE_DEALLOC: > > - pp_string (pp, "force_dealloc"); > > + pp_string (pp, "always,delete"); > > break; > > case GOMP_MAP_FORCE_DEVICEPTR: > > pp_string (pp, "force_deviceptr"); > > Makes some sense to me to use the same "always,*" syntax also for the > other "force_*" ones, given that these are artificial ("non-OpenACC") > descriptions anyway. Ok. Are the GOMP_MAP_FORCE_* artificial too? If yes, I can change that to GOMP_MAP_ALWAYS_*. Anyway, for most of the further 4.1 offloading I'll defer to Ilya Verbin and Kyrill as agreed privately on IRC, I'll focus for now on the task / doacross etc. stuff for now (and, hopefully if enough of the OpenACC stuff is merged in soon, restart work on the OpenMP 4.0 / NVPTX offloading too, but that not on this branch). Jakub