From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89064 invoked by alias); 22 Jan 2016 08:36:33 -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 89048 invoked by uid 89); 22 Jan 2016 08:36:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=pragmas, Hx-languages-length:2036, singlethreaded 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; Fri, 22 Jan 2016 08:36:32 +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 EC6C7C0AC912; Fri, 22 Jan 2016 08:36:30 +0000 (UTC) Received: from tucnak.zalov.cz ([10.3.113.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0M8aTsS007318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Jan 2016 03:36:30 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id u0M8aRlY015022; Fri, 22 Jan 2016 09:36:27 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id u0M8aPjg015021; Fri, 22 Jan 2016 09:36:25 +0100 Date: Fri, 22 Jan 2016 08:36:00 -0000 From: Jakub Jelinek To: Thomas Schwinge Cc: gcc-patches@gcc.gnu.org Subject: Re: [gomp4] Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading" Message-ID: <20160122083625.GL3017@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <87r3hac1w9.fsf@hertz.schwinge.homeip.net> <569D2059.4010105@mentor.com> <87d1subnu5.fsf@hertz.schwinge.homeip.net> <87a8nyawph.fsf@hertz.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a8nyawph.fsf@hertz.schwinge.homeip.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg01707.txt.bz2 On Fri, Jan 22, 2016 at 08:40:26AM +0100, Thomas Schwinge wrote: > On Thu, 21 Jan 2016 22:54:26 +0100, I wrote: > > On Mon, 18 Jan 2016 18:26:49 +0100, Tom de Vries wrote: > > > [...] [OpenACC] kernels region [...] > > > that parloops does not manage to parallelize: > > > Telling from real-world code that we've been having a look at, when the > > above situation happens, we're -- in the vast majority of all cases -- in > > a situation where we generally want to avoid offloading (unless > > explicitly requested), "to avoid data copy penalty" as well as typically > > much slower single-threaded execution on the GPU. Obviously, that will > > have to be revisited as parloops (or any other mechanism in GCC) is able > > to better understand/use the parallelism in OpenACC kernels constructs. > > > > So, building upon Tom's patch, I have implemented an "avoid offloading" > > flag given the presence of one un-parallelized OpenACC kernels construct. > > This is currently only enabled for OpenACC kernels constructs, in > > combination with nvptx offloading, but I think the general scheme will be > > useful also for other constructs as well as other (non-shared memory) > > offloading targets. > > > Committed to gomp-4_0-branch in r232709: > > > > commit 41a76d233e714fd7b79dc1f40823f607c38306ba > > Author: tschwinge > > Date: Thu Jan 21 21:52:50 2016 +0000 > > > > Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading" > > Thought I'd check before porting it over -- will such a patch also be > accepted for trunk? I think it is a bad idea to go against what the user wrote. Warning that some code might not be efficient? Perhaps (if properly guarded with some warning option one can turn off, either on a per-source file or using pragmas even more fine grained). But by default not offloading? That is just wrong. Jakub