From patchwork Mon Oct 12 16:56:29 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: 529226 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 0050F1400CB for ; Tue, 13 Oct 2015 03:57:35 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=heyMn7ag; 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=h33YJcFfoz0I1mSFA /Hb+pV/c9oZo+2H7np3wl83vhaYor3Ok5TCNdDVR2XNQf+pOrVSzMT78RJnfR1z6 1u0aq7EXtFOqwePLcHcoPjym3Bqlsnycn1aHfpImpUHrYK2EYelfucD8SrbXmGae JdyLxOE2J7ML52WqlQpw74OyL4= 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=2SNfPGudn50uPIffNVbGyxQ EwmI=; b=heyMn7agk+yzkQ80BUa2kSPiemF/HlARR9SenbaB5Z/aLow4/B1gJBL tLfzBBYOS2aVfHEgxLO1ghQD5Re8n1yuWt7dmKktJ/7j1Hpak55WzWT1kcAhNljv zFC1C9FVs4hDB5k9ifqFJxN4CWWiELYcx2Su91StYnhb7HmzTd9s= Received: (qmail 64161 invoked by alias); 12 Oct 2015 16:57:27 -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 64152 invoked by uid 89); 12 Oct 2015 16:57:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: fencepost.gnu.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (208.118.235.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 12 Oct 2015 16:57:25 +0000 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42748) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ZlgPa-0003G6-I1 for gcc-patches@gnu.org; Mon, 12 Oct 2015 12:57:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlgPW-0006Zq-P3 for gcc-patches@gnu.org; Mon, 12 Oct 2015 12:57:22 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:50161) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlgPW-0006Yi-Hn for gcc-patches@gnu.org; Mon, 12 Oct 2015 12:57:18 -0400 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 1ZlgPU-0006e3-8Y from Tom_deVries@mentor.com ; Mon, 12 Oct 2015 09:57:16 -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, 12 Oct 2015 17:57:14 +0100 Subject: Re: [PATCH, 3/5] Handle original loop tree in expand_omp_for_generic To: Bernd Schmidt References: <560100FF.9060904@mentor.com> <5601343C.9010104@redhat.com> <56114774.9090108@mentor.com> <561394CA.1050504@redhat.com> <5618F121.4070100@mentor.com> <5618FD7E.6060505@mentor.com> <561BBF8D.7040602@redhat.com> CC: "gcc-patches@gnu.org" From: Tom de Vries Message-ID: <561BE63D.2030907@mentor.com> Date: Mon, 12 Oct 2015 18:56:29 +0200 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: <561BBF8D.7040602@redhat.com> X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] [fuzzy] X-Received-From: 192.94.38.131 On 12/10/15 16:11, Bernd Schmidt wrote: > On 10/10/2015 01:58 PM, Tom de Vries wrote: > >> Handle original loop tree in expand_omp_for_generic >> >> 2015-09-10 Tom de Vries >> >> PR tree-optimization/67476 >> * omp-low.c (expand_omp_for_generic): Handle original loop tree. > > This one I find slightly confusing. > >> - add_bb_to_loop (l2_bb, cont_bb->loop_father); >> + struct loop *loop = l1_bb->loop_father; >> + add_bb_to_loop (l2_bb, entry_bb->loop_father); >> add_loop (outer_loop, l0_bb->loop_father); > > Looks like a lot of bb's loop_father is being looked at. Are all or some > of these supposed to be the same? I think I'd like one (appropriately > named) struct loop * variable for each loop that's involved here. Done. > There's a comment suggesting that there can be different situations, it > would be good to expand that to explain how they can arise. > >> - struct loop *loop = alloc_loop (); >> + loop = alloc_loop (); > > Also, I think it would be preferrable to not reuse that loop variable > but make a new one instead. > Does this version look better? Thanks, - Tom Handle original loop tree in expand_omp_for_generic 2015-09-12 Tom de Vries PR tree-optimization/67476 * omp-low.c (expand_omp_for_generic): Handle original loop tree. --- gcc/omp-low.c | 30 +++++++++++++++++++++--------- 1 file changed, 21 insertions(+), 9 deletions(-) diff --git a/gcc/omp-low.c b/gcc/omp-low.c index b2a93b9..b957428 100644 --- a/gcc/omp-low.c +++ b/gcc/omp-low.c @@ -6439,7 +6439,6 @@ expand_omp_for_generic (struct omp_region *region, remove_edge (e); make_edge (cont_bb, l2_bb, EDGE_FALSE_VALUE); - add_bb_to_loop (l2_bb, cont_bb->loop_father); e = find_edge (cont_bb, l1_bb); if (e == NULL) { @@ -6516,17 +6515,30 @@ expand_omp_for_generic (struct omp_region *region, set_immediate_dominator (CDI_DOMINATORS, l1_bb, recompute_dominator (CDI_DOMINATORS, l1_bb)); - struct loop *outer_loop = alloc_loop (); - outer_loop->header = l0_bb; - outer_loop->latch = l2_bb; - add_loop (outer_loop, l0_bb->loop_father); + /* We enter expand_omp_for_generic with a loop. This original loop may + have its own loop struct, or it may be part of an outer loop struct + (which may be the fake loop). */ + struct loop *outer_loop = entry_bb->loop_father; + bool orig_loop_has_loop_struct = l1_bb->loop_father != outer_loop; - if (!gimple_omp_for_combined_p (fd->for_stmt)) + add_bb_to_loop (l2_bb, outer_loop); + + /* We've added a new loop around the original loop. Allocate the + corresponding loop struct. */ + struct loop *new_loop = alloc_loop (); + new_loop->header = l0_bb; + new_loop->latch = l2_bb; + add_loop (new_loop, outer_loop); + + if (/* If we already have a loop struct for the original loop, don't + allocate a new one. */ + !orig_loop_has_loop_struct + && !gimple_omp_for_combined_p (fd->for_stmt)) { - struct loop *loop = alloc_loop (); - loop->header = l1_bb; + struct loop *orig_loop = alloc_loop (); + orig_loop->header = l1_bb; /* The loop may have multiple latches. */ - add_loop (loop, outer_loop); + add_loop (orig_loop, new_loop); } } } -- 1.9.1