From patchwork Wed Sep 12 11:47:16 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Bruel X-Patchwork-Id: 183340 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]) by ozlabs.org (Postfix) with SMTP id 5A0C02C0081 for ; Wed, 12 Sep 2012 21:48:01 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1348055282; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Message-ID:Date:From:User-Agent:MIME-Version: To:Cc:Subject:References:In-Reply-To:Content-Type:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=1aeN7LC+xcHTFugNqgWW8BB3SDE=; b=a9jdCBPBo3S+Ybe+hnAya+Pe9s35HiupdYGgQYS+towYmpm3rVGOvtqvKFHTFU 4OsMW90K4QveN3j+wgF8DrvN50m9EcSCYuUg8qrkqwQNn75lsV1+GwMWXNZL4hcW Vf5hCaPJaLubTugUaoYPomp4g7vNjuzaJnEvbPBwI0dns= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Cc:Subject:References:In-Reply-To:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=HvXAYv+I1rXck1yVr26+LT1P7KkZOTkaEdSUnu/iPn4nJ+uIQFFmwrI3wdDcW5 dXYSQuPgoWOwhMM1h3TA2kWyfRKUBefqKb52rp7WBKDEZjE0aOIKjMnyot8L+5eF 9coM3veT2WxNfE0LZJGC8sr0xsHtAkaJLrxDbpoZpYEl8=; Received: (qmail 2184 invoked by alias); 12 Sep 2012 11:47:57 -0000 Received: (qmail 2173 invoked by uid 22791); 12 Sep 2012 11:47:56 -0000 X-SWARE-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_HOSTKARMA_W, RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from eu1sys200aog104.obsmtp.com (HELO eu1sys200aog104.obsmtp.com) (207.126.144.117) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Sep 2012 11:47:42 +0000 Received: from beta.dmz-eu.st.com ([164.129.1.35]) (using TLSv1) by eu1sys200aob104.postini.com ([207.126.147.11]) with SMTP ID DSNKUFB2WB72j1A1CSmpgbFwh+u3RRGIIMTX@postini.com; Wed, 12 Sep 2012 11:47:42 UTC Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 53BE8249; Wed, 12 Sep 2012 11:47:17 +0000 (GMT) Received: from Webmail-eu.st.com (safex1hubcas1.st.com [10.75.90.14]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 117E42D68; Wed, 12 Sep 2012 11:47:17 +0000 (GMT) Received: from [164.129.122.89] (164.129.122.89) by webmail-eu.st.com (10.75.90.13) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 12 Sep 2012 13:47:16 +0200 Message-ID: <50507644.7090503@st.com> Date: Wed, 12 Sep 2012 13:47:16 +0200 From: Christian Bruel User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Jakub Jelinek Cc: Steven Bosscher , "gcc-patches@gcc.gnu.org" Subject: Re: shrink-wrapping duplicates BBs across partitions. References: <504F2DA8.3050208@st.com> <504F595B.1030403@st.com> <20120911162134.GV22619@tucnak.redhat.com> In-Reply-To: <20120911162134.GV22619@tucnak.redhat.com> X-IsSubscribed: yes 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 The problem stems from tree-ssa-tail-merge that breaks bb->count, The CFG looks like 2 / \ / 6 5 (0) | | 3 <----- | / \ | | 7 (1) 8 - | / 4 (1) (in parenthesis the bb->count from gcov) 2 / \ / 6 / | | 3 <-- | / | | 5 (0) 8 -- | | 4 (1) so 5 and 4 are now in different partitions, producing an assertion because there is no EDGE_CROSSING between them. I can see 3 solutions to this 1) merge the BB counts in tree-ssa-tail-merge.c, so 5 is in the same partition that 4 2) don't tail-merge blocks that belong to different partitions. 3) add a EDGE_CROSSING flag on the edge between 4 and 5. 1) fixes the problem, so 5 and 4 are now in the same partition. The fix is quite trivial, as with attached. the other solution 2) is more conservative, and also fixes the problem. I don't think 3) is necessary. more ideas ? thanks, Christian On 09/11/2012 06:21 PM, Jakub Jelinek wrote: > On Tue, Sep 11, 2012 at 05:40:30PM +0200, Steven Bosscher wrote: >> On Tue, Sep 11, 2012 at 5:31 PM, Christian Bruel wrote: >>> Actually, the edge is fairly simple. I have >>> >>> BB5 (BB_COLD_PARTITION) -> BB10 (BB_HOT_PARTITION) -> EXIT >>> >>> and BB10 has no other incoming edges. and we are duplicating it. >> >> That is wrong, should never happen. Is there a test case to play with? >> It'd be good to have a PR for this. > > Isn't that the standard case when !HAVE_return ? Then you can have only a > single return through epilogue, and when the epilogue is in the hot > partition, even if cold code is returning, it needs to jump to the epilogue. > > Jakub > Index: tree-ssa-tail-merge.c =================================================================== --- tree-ssa-tail-merge.c (revision 191129) +++ tree-ssa-tail-merge.c (working copy) @@ -1478,6 +1478,8 @@ bb2->frequency = BB_FREQ_MAX; bb1->frequency = 0; + bb2->count += bb1->count; + /* Do updates that use bb1, before deleting bb1. */ release_last_vdef (bb1); same_succ_flush_bb (bb1);