From patchwork Tue Jan 12 10:17:32 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 566448 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 B9354140134 for ; Tue, 12 Jan 2016 21:17:48 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=SSMpOvFp; 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:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=FgnKfQ/qBeSSnSXJt i4AKP+ro1wQSAzYjQqS14aqJTqqck/j7W15woDEOJE8LI5z48ZQfbDbvRhzSEQS7 RIobck+U6jqruC4+gtREtiiiYeDr7PUyZjIXyldSEbhDFUe79hggZEH17nMMF9Xx dj3QxLRt6d1JLUENAZfm3lslYw= 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:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; s=default; bh=OPIhFC8YSNAVPaMuDSlLlMk xU/8=; b=SSMpOvFpSVEyBfOSkWOBoqcAZpgNrbl9gFq3ndF3kd8ixMtyyJFGvDm F0YQxNVd8zZ9ulR9PhlgHdNeNE+7zvRNCZpC16chGbWTgPqUWiD4i7Hf6B1QljxK lDr8Gyy2yANskA9gH4/Od0KRzicSTOZWte4xTaL5BV4ciqOWHy0M= Received: (qmail 70315 invoked by alias); 12 Jan 2016 10:17:41 -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 70304 invoked by uid 89); 12 Jan 2016 10:17:40 -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=UD:cfgcleanup.c, cfgcleanup.c, cfgcleanupc, armv7a 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; Tue, 12 Jan 2016 10:17:39 +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 3B711C0BF2B7; Tue, 12 Jan 2016 10:17:38 +0000 (UTC) Received: from tucnak.zalov.cz ([10.3.113.3]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0CAHaZ2027608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Jan 2016 05:17:37 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id u0CAHYhm002373; Tue, 12 Jan 2016 11:17:35 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id u0CAHWPG002372; Tue, 12 Jan 2016 11:17:32 +0100 Date: Tue, 12 Jan 2016 11:17:32 +0100 From: Jakub Jelinek To: Bernd Schmidt Cc: Jeff Law , gcc-patches@gcc.gnu.org, Kyrill Tkachov Subject: [PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175, take 2) Message-ID: <20160112101732.GC3017@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20160108201728.GF18720@tucnak.redhat.com> <56902591.8000209@redhat.com> <20160108212310.GL18720@tucnak.redhat.com> <569032B6.4030200@redhat.com> <569045C6.5070202@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <569045C6.5070202@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes On Sat, Jan 09, 2016 at 12:27:02AM +0100, Bernd Schmidt wrote: > Well, I checked a bit more. Most callers of merge_blocks seem to already > look for barriers if they are a concern and remove them. This occurs > multiple times in ifcvt.c and cfgcleanup.c. Oddly, > merge_blocks_move_predecessor_nojumps uses next_nonnote_insn to find the > barrier, while merge_blocks_move_successor_nojumps uses just NEXT_INSN. That > should probably be fixed too. > > So the situation is a bit odd in that most callers remove the barrier but > merge_blocks tries to handle an isolated barrier as well. The area could > probably cleaned up a little, but on the whole I still lean towards > requiring the caller to remove an isolated barrier. That leaves the RTL in a > more consistent state before the call to merge_blocks. So is the following ok for trunk? Bootstrapped/regtested on x86_64-linux and i686-linux, and Kyrill has kindly bootstrapped/regtested it on arm too. 2016-01-12 Jakub Jelinek PR target/69175 * ifcvt.c (cond_exec_process_if_block): When removing the last insn from then_bb, remove also any possible barriers that follow it. * g++.dg/opt/pr69175.C: New test. Jakub --- gcc/ifcvt.c.jj 2016-01-04 14:55:53.000000000 +0100 +++ gcc/ifcvt.c 2016-01-11 16:13:22.833174933 +0100 @@ -739,7 +739,7 @@ cond_exec_process_if_block (ce_if_block rtx_insn *from = then_first_tail; if (!INSN_P (from)) from = find_active_insn_after (then_bb, from); - delete_insn_chain (from, BB_END (then_bb), false); + delete_insn_chain (from, get_last_bb_insn (then_bb), false); } if (else_last_head) delete_insn_chain (first_active_insn (else_bb), else_last_head, false); --- gcc/testsuite/g++.dg/opt/pr69175.C.jj 2016-01-08 13:04:04.084805432 +0100 +++ gcc/testsuite/g++.dg/opt/pr69175.C 2016-01-08 13:03:47.000000000 +0100 @@ -0,0 +1,29 @@ +// PR target/69175 +// { dg-do compile } +// { dg-options "-O2" } +// { dg-additional-options "-march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb" { target { arm_hard_vfp_ok && arm_thumb2_ok } } } + +struct A { A *c, *d; } a; +struct B { A *e; A *f; void foo (); }; +void *b; + +void +B::foo () +{ + if (b) + { + A *n = (A *) b; + if (b == e) + if (n == f) + e = __null; + else + e->c = __null; + else + n->d->c = &a; + n->d = e; + if (e == __null) + e = f = n; + else + e = n; + } +}