From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70741 invoked by alias); 9 Jun 2015 20:24:34 -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 70726 invoked by uid 89); 9 Jun 2015 20:24:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no 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; Tue, 09 Jun 2015 20:24:33 +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 CE4938E50C; Tue, 9 Jun 2015 20:24:31 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-89.ams2.redhat.com [10.36.116.89]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t59KOUnA006468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Jun 2015 16:24:31 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t59KOS4i012159; Tue, 9 Jun 2015 22:24:28 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t59KOQlL012158; Tue, 9 Jun 2015 22:24:26 +0200 Date: Tue, 09 Jun 2015 20:25:00 -0000 From: Jakub Jelinek To: Ilya Verbin Cc: Thomas Schwinge , gcc-patches@gcc.gnu.org, Kirill Yukhin , Richard Henderson Subject: Re: [gomp4.1] Initial support for some OpenMP 4.1 construct parsing Message-ID: <20150609202426.GG10247@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150609183608.GA47936@msticlxl57.ims.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00708.txt.bz2 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 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. [...] > > TR3.pdf also says about 'release' map-type for exit data, but it is not > described in the document. Seems that is the case even in the latest draft. Can you file a ticket for this or discuss on omp-lang? Or should I? > > [...] And, we'll need new > > arguments for async (pass through info that it is async (nowait) or sync, > > and the depend clause address(es)). > > I don't quite understand from "If a depend clause is present, then it is treated > as if it had appeared on the implicit task construct that encloses the target > construct", is > > #pragma omp target depend(inout: x) > > equivalent to > > #pragma omp task depend(inout: x) > #pragma omp target > > or not? > > In other words, can't we just generate GOMP_task (...) with GOMP_target (...) > inside, without any new arguments? No, that would be an explicit task. Furthermore, the implicit task isn't on the host side, but on the offloading device side. The implicit task is what is executed when you enter the #pragma omp target. Ignoring the teams construct which is there mainly for NVidia GPGPUs, when you enter the #pragma omp target construct, there is an implicit parallel with num_threads(1) (like there is an implicit parallel with num_threads(1) when you enter main () of a host program), and that implicit parallel has a single implicit task, which executes the statements inside of #pragma omp target body, until you encounter #pragma omp teams or #pragma omp parallel. And the above statement simply says that no statements from the #pragma omp target body are executed until the depend dependency is satisfied. Whether these dependencies are host addresses, or offloading device addresses, is something that really needs to be figured out, I admit I haven't read the whole async offloading text carefully yet, nor participated in the telecons about it. Jakub