From patchwork Mon Jun 22 17:59:45 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: 487319 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 93D1E1401B5 for ; Tue, 23 Jun 2015 04:00:06 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=swNGLTIi; 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 :message-id:date:from:mime-version:to:subject:content-type; q= dns; s=default; b=RYDBfH7I8OJQYnh+A7GF1rQFEc9cLKvS1ftqDBdytB1IgX coHm8ai9W/GQz8SrXwLpbIWlKVAv3Z2dkWT/KFLXMgHMkjO9wRj6H8EAgpc2Ke5n nalHQH6dAzaiw2oY7yrD4dp9CO/FhY3FIfXh07b5F+eKglJqpwMTHkU+8rDW0= 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 :message-id:date:from:mime-version:to:subject:content-type; s= default; bh=inarQSwGKVWyrzyHahq/Z5uSTxU=; b=swNGLTIiPWDNcsbZdOlR T7KxUvcoFIZ1mxJLJ7bUgqqzfwkRJEmkHqqAYRWSR4iZa7onmRgcLP1wKlURzH22 kaYzAk8VsIvhy9uxUhZbq1ZHlX5rN9AQH5TFfZN2EaZkHAEiI2piKmFaUE7XvaCb Ik5VnqOYZLLpNkpTzghZvOI= Received: (qmail 107038 invoked by alias); 22 Jun 2015 17:59:59 -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 107025 invoked by uid 89); 22 Jun 2015 17:59:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 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; Mon, 22 Jun 2015 17:59:56 +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 1Z760e-0004jC-Q0 from Tom_deVries@mentor.com ; Mon, 22 Jun 2015 10:59:53 -0700 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; Mon, 22 Jun 2015 18:59:51 +0100 Message-ID: <55884D11.30300@mentor.com> Date: Mon, 22 Jun 2015 19:59:45 +0200 From: Tom de Vries User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Richard Biener , GCC Patches Subject: [PATCH] parloops exit phi fixes Hi, the gomp-4_0-branch contains the kernels oacc pass group. I've run into trouble before with this pass group due to the fact that it uses passes in an unusual location or order (pass_lim before pass_stdarg, https://gcc.gnu.org/ml/gcc/2015-01/msg00282.html ). In an attempt to find this sort of issue pro-actively, I've modified the pass list in the following way (similar to the oacc kernels pass group, but always functional, not just for functions with kernel regions or loops in kernels regions), and bootstrapped and reg-tested on x86_64 on top of gomp-4_-0-branch: ... NEXT_PASS (pass_build_ealias); NEXT_PASS (pass_fre); + NEXT_PASS (pass_ch); + NEXT_PASS (pass_tree_loop_init); + NEXT_PASS (pass_lim); + NEXT_PASS (pass_tree_loop_done); + NEXT_PASS (pass_fre); + NEXT_PASS (pass_tree_loop_init); + NEXT_PASS (pass_scev_cprop); + NEXT_PASS (pass_parallelize_loops); + NEXT_PASS (pass_expand_omp_ssa); + NEXT_PASS (pass_tree_loop_done); NEXT_PASS (pass_merge_phi); NEXT_PASS (pass_dse); ... Apart from running into PR66616, I found two issues with the parloops pass: 1. handling of loop header phi, when there's no corresponding loop exit phi (unused reduction result) 2. handling of loop exit phi, when there's no corresponding loop header phi (value not modified in loop) The two attached patches fix these problems. Bootstrapped and reg-tested on x864_64 on top of gomp-4_0-branch in combination with the patch series that triggered the problem. Bootstrapped and reg-tested on x864_64 on top of trunk. OK for trunk? Thanks, - Tom Handle exit phi without header phi in create_parallel_loop 2015-06-22 Tom de Vries * tree-parloops.c (create_parallel_loop): Handle case that exit phi does not have a corresponding loop header phi. --- gcc/tree-parloops.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/gcc/tree-parloops.c b/gcc/tree-parloops.c index 7123c27..0693b9e 100644 --- a/gcc/tree-parloops.c +++ b/gcc/tree-parloops.c @@ -2061,13 +2061,17 @@ create_parallel_loop (struct loop *loop, tree loop_fn, tree data, !gsi_end_p (gpi); gsi_next (&gpi)) { source_location locus; - tree def; gphi *phi = gpi.phi (); - gphi *stmt; + tree def = PHI_ARG_DEF_FROM_EDGE (phi, exit); + gimple def_stmt = SSA_NAME_DEF_STMT (def); - stmt = as_a ( - SSA_NAME_DEF_STMT (PHI_ARG_DEF_FROM_EDGE (phi, exit))); + /* If the exit phi is not connected to a header phi in the same loop, this + value is not modified in the loop, and we're done with this phi. */ + if (!(gimple_code (def_stmt) == GIMPLE_PHI + && gimple_bb (def_stmt) == loop->header)) + continue; + gphi *stmt = as_a (def_stmt); def = PHI_ARG_DEF_FROM_EDGE (stmt, loop_preheader_edge (loop)); locus = gimple_phi_arg_location_from_edge (stmt, loop_preheader_edge (loop)); -- 1.9.1