From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51727 invoked by alias); 20 Apr 2017 16:48:02 -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 51636 invoked by uid 89); 20 Apr 2017 16:48:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= 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 ESMTP; Thu, 20 Apr 2017 16:48:00 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7117CC073D57; Thu, 20 Apr 2017 16:48:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7117CC073D57 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7117CC073D57 Received: from tucnak.zalov.cz (ovpn-116-29.ams2.redhat.com [10.36.116.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F1114800E9; Thu, 20 Apr 2017 16:47:58 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v3KGlt27023523; Thu, 20 Apr 2017 18:47:55 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v3KGls2l023522; Thu, 20 Apr 2017 18:47:54 +0200 Date: Thu, 20 Apr 2017 17:29:00 -0000 From: Jakub Jelinek To: Alexander Monakov Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH 2/5] omp-low: implement SIMT privatization, part 1 Message-ID: <20170420164754.GX1809@tucnak> Reply-To: Jakub Jelinek References: <1490197595-31938-1-git-send-email-amonakov@ispras.ru> <1490197595-31938-3-git-send-email-amonakov@ispras.ru> <20170323103159.GM11094@tucnak> <20170420151622.GV1809@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00911.txt.bz2 On Thu, Apr 20, 2017 at 07:37:13PM +0300, Alexander Monakov wrote: > On Thu, 20 Apr 2017, Jakub Jelinek wrote: > > > This wasn't caught in testing, as apparently all testcases that have target > > > simd loops with linear/lastprivate clauses also have the corresponding variables > > > mentioned in target map clause, which makes them addressable (is that necessary?), > > > > Yes, in order to map something you need to map its address (+ size) on the > > host to its address on the device, so it needs to be addressable. > > Compared to that, firstprivate on target should not make it addressable. > > But ideally if nothing else is taking the address of a mapped variable inside > of a target region, then it'd be more efficient to create a non-addressable > instance and just copy its value from/to the addressable one on target > region entry/exit. Perhaps, but you'd need to do only if it is map on the target construct because that is the only case where you can actually add copy in/out code on the host as well as target. And you'd need to think about nowait implications etc., or what happens if it in addition to target construct is mentioned in map clause on some other construct etc., i.e. take into account all the clauses of the variable in the scope of the variable, not just a single one. That is GCC8 material for sure. If it is say map(to:), it could as well be just promotion into firstprivate, or for map(alloc:) to private etc. > > Would be nice to also test explicit linear, perhaps in the same testcase, > > just add ch and c and use say linear(c:2). > > Unfortunately that uncovers a separate wrong-code issue, explicit linear is > not specifically handled in simt regions, but it should be, since we change > the loop iteration step. Then please commit what you have now and deal with the rest incrementally. Jakub