From patchwork Sun Nov 8 15:45:49 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 541461 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3E01514031F for ; Mon, 9 Nov 2015 02:46:29 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=AenVpajg; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; q=dns; s=default; b=obocgqVTl/E3f2/jK TSBENnbvmzZk7oHjCD+Ss/wJ63J0sNCL0QqIyPz670Ikhw/XVosdHw8DuKLfm4JE wijxJ37C8j/o3X+saZJtOULW6TyYfP02Qg8wJqKr3MLa6yPhJ1Ghoa7pI07GsvzX w3qKW8Co7w4rDtz8u/qaCq9NcE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; s=default; bh=0KQxho6kUmWEVYq/KipMUiq q8Jc=; b=AenVpajgp6kiUwC9jFTL2mAFl7g0kvJvVpTqTV6a8sQQwilfyCWUd7o PR39bnP+zBa9Rpg1cD3U9gTXUInxBr248gUhM6X/uOhZGyt2gWwjoJaP4wybcU4G xbcaERHDg0OMjTUhi0HagS/r8ThAsVL7FTGoG73CwXRtFsXSzAHg= Received: (qmail 9918 invoked by alias); 8 Nov 2015 15:46:20 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 9895 invoked by uid 89); 8 Nov 2015 15:46:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 08 Nov 2015 15:46:16 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1ZvSAX-00039p-CN from Tom_deVries@mentor.com for gcc-patches@gcc.gnu.org; Sun, 08 Nov 2015 07:46:13 -0800 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Sun, 8 Nov 2015 15:46:12 +0000 Subject: Re: Combined constructs' clause splitting To: Thomas Schwinge , Tom de Vries References: <563B8E1E.1020400@codesourcery.com> <563D0735.7070601@mentor.com> <87h9lqaofq.fsf@schwinge.name> <563D384B.809@codesourcery.com> <87fv0ixcbo.fsf@kepler.schwinge.homeip.net> CC: "gcc-patches@gcc.gnu.org" , Nathan Sidwell , Cesar Philippidis From: Tom de Vries Message-ID: <563F6E2D.7070107@mentor.com> Date: Sun, 8 Nov 2015 16:45:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <87fv0ixcbo.fsf@kepler.schwinge.homeip.net> On 07/11/15 12:45, Thomas Schwinge wrote: > Hi! > > On Fri, 6 Nov 2015 15:31:23 -0800, Cesar Philippidis wrote: >> I've applied this patch to gomp-4_0-branch which backports most of my >> front end changes from trunk. Note that I found a regression while >> testing, which is also present in trunk. It looks like >> kernels-acc-loop-reduction.c is failing because I'm incorrectly >> propagating the reduction variable to both to the kernels and loop >> constructs for combined 'acc kernels loop'. The problem here is that >> kernels don't support the reduction clause. I'll fix that next week. > > Always need to consider both what the specification allows -- and thus > what the front ends accept/refuse -- as well as what we might do > differently, internally in later processing stages. I have not analyzed > whether it makes sense to have the OMP_CLAUSE_REDUCTION of a combined > "kernels loop reduction([...])" construct be attached to the outer > OACC_KERNELS or inner OACC_LOOP, or duplicated for both. > > Tom, if you need a solution for that right now/want to restore the > previous behavior (attached to innter OACC_LOOP only), here's what you > should try: in gcc/c-family/c-omp.c:c_oacc_split_loop_clauses remove the > special handling for OMP_CLAUSE_REDUCTION, and move it to "Loop clauses" > section, Committed to gomp-4_0-branch, as attached. Thanks, - Tom > and in > gcc/fortran/trans-openmp.c:gfc_trans_oacc_combined_directive I don't see > reduction clauses being handled, hmm, maybe the Fortran front end is > doing that differently? > > Ignore reduction clause on kernels directive 2015-11-08 Tom de Vries * c-omp.c (c_oacc_split_loop_clauses): Don't copy OMP_CLAUSE_REDUCTION, classify as loop clause. --- gcc/c-family/c-omp.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/gcc/c-family/c-omp.c b/gcc/c-family/c-omp.c index 8b30844..907d329 100644 --- a/gcc/c-family/c-omp.c +++ b/gcc/c-family/c-omp.c @@ -867,7 +867,7 @@ c_omp_check_loop_iv_exprs (location_t stmt_loc, tree declv, tree decl, tree c_oacc_split_loop_clauses (tree clauses, tree *not_loop_clauses) { - tree next, loop_clauses, t; + tree next, loop_clauses; loop_clauses = *not_loop_clauses = NULL_TREE; for (; clauses ; clauses = next) @@ -886,16 +886,11 @@ c_oacc_split_loop_clauses (tree clauses, tree *not_loop_clauses) case OMP_CLAUSE_SEQ: case OMP_CLAUSE_INDEPENDENT: case OMP_CLAUSE_PRIVATE: + case OMP_CLAUSE_REDUCTION: OMP_CLAUSE_CHAIN (clauses) = loop_clauses; loop_clauses = clauses; break; - /* Reductions belong in both constructs. */ - case OMP_CLAUSE_REDUCTION: - t = copy_node (clauses); - OMP_CLAUSE_CHAIN (t) = loop_clauses; - loop_clauses = t; - /* FIXME: device_type */ /* Parallel/kernels clauses. */ -- 1.9.1