From patchwork Thu Mar 8 18:04:20 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rong Xu X-Patchwork-Id: 145600 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 BE15BB6EE6 for ; Fri, 9 Mar 2012 05:04:43 +1100 (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=1331834684; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Received:Received:To:Subject:Message-Id:Date: From:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=gy3AJ1v vS9n0Q0YoNY+JguR9BFI=; b=GbuApqv14qeKfHstrwREDJQOx+cZkFRKf4pvRvT OngD5Z8PTbNwcYAEXtW+FLanXdRrRQffK7XoEbhqc04fqihAvSYf2R6DZ6zSQ9YP mxIVpu0Xna6cuYzEnZlSw0YyGD42C0e0WQhGDIs2PvFXXwzvb3ozc8sEiyVLqY5y /xO4= 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:Received:Received:To:Subject:Message-Id:Date:From:X-Gm-Message-State:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=fZCqFPG++rPQ3TunqxBcT7CxHj6NnvVtVSiLvWEq+KriwIs12Q0Fm9jAmTIlV2 OCORQzNTZFKFC+SwAp019CttlTVmHFWbNFpdgEaKglFY2Cnw7pYwceOh7uEmNXj3 891U/tmn6uDgKQTYJPD6tIbwbo0xqczHCvbMNbO6oaie0=; Received: (qmail 28726 invoked by alias); 8 Mar 2012 18:04:39 -0000 Received: (qmail 28718 invoked by uid 22791); 8 Mar 2012 18:04:37 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-lpp01m010-f73.google.com (HELO mail-lpp01m010-f73.google.com) (209.85.215.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Mar 2012 18:04:22 +0000 Received: by laah2 with SMTP id h2so27192laa.2 for ; Thu, 08 Mar 2012 10:04:21 -0800 (PST) Received: by 10.14.51.7 with SMTP id a7mr2405287eec.6.1331229861415; Thu, 08 Mar 2012 10:04:21 -0800 (PST) Received: by 10.14.51.7 with SMTP id a7mr2405276eec.6.1331229861319; Thu, 08 Mar 2012 10:04:21 -0800 (PST) Received: from hpza10.eem.corp.google.com ([74.125.121.33]) by gmr-mx.google.com with ESMTPS id f9si1704694eea.2.2012.03.08.10.04.21 (version=TLSv1/SSLv3 cipher=AES128-SHA); Thu, 08 Mar 2012 10:04:21 -0800 (PST) Received: from rong.mtv.corp.google.com (rong.mtv.corp.google.com [172.18.110.233]) by hpza10.eem.corp.google.com (Postfix) with ESMTP id 245DD200057; Thu, 8 Mar 2012 10:04:21 -0800 (PST) Received: by rong.mtv.corp.google.com (Postfix, from userid 104659) id 61792C1D5C; Thu, 8 Mar 2012 10:04:20 -0800 (PST) To: reply@codereview.appspotmail.com, davidxl@google.com, gcc-patches@gcc.gnu.org Subject: [google] [4.6] fix a bug in capping bb count scaling (issue5786054) Message-Id: <20120308180420.61792C1D5C@rong.mtv.corp.google.com> Date: Thu, 8 Mar 2012 10:04:20 -0800 (PST) From: xur@google.com (Rong Xu) X-Gm-Message-State: ALoCoQn8x502fYe5XNiy5Z5QnSLASfu1zu8PPy2ZWKiDWOyoYP3Xe0f4kWi+jivQVa+ZL96eqFv6vH2lYd5mL8ggOLdkjdVddI4AIHiwe3eA7zdyF5W85+Qd1XPXZCt8DGgG9nN+5NCId//32PTxNuiTBuriO+DNcYhR/lXR/D3DHc7+azGbmHA= 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 Hi, This patch is for google-4_6 branch only. It fixes a bug in r184378 which makes some capping escape (like stale max_bb_count in cgraph node). Tested with the internal benchmark that exposes this issue. Tested with gcc bootstrap. -Rong 2012-03-08 Rong Xu * gcc/tree-inline.c (copy_cfg_body): fix the bug in r184378. Google ref b/6105259. --- This patch is available for review at http://codereview.appspot.com/5786054 Index: gcc/tree-inline.c =================================================================== --- gcc/tree-inline.c (revision 185095) +++ gcc/tree-inline.c (working copy) @@ -2210,7 +2210,7 @@ struct cgraph_node *node = cgraph_node (callee_fndecl); double f_max; gcov_type max_count_scale; - gcov_type max_src_bb_cnt; + gcov_type max_src_bb_cnt = 0; gcov_type max_value = ((gcov_type) 1 << ((sizeof(gcov_type) * 8) - 1)); max_value = ~max_value; count_scale = (REG_BR_PROB_BASE * (double)count @@ -2220,14 +2220,13 @@ This can happen for comdat functions where the counters are split. It's more likely for recursive inlines. */ gcc_assert (node); - max_src_bb_cnt = node->max_bb_count; /* Find the maximum count value to that will be copied. */ FOR_EACH_BB_FN (bb, cfun_to_copy) if (!blocks_to_copy || bitmap_bit_p (blocks_to_copy, bb->index)) { - if (bb->count > node->max_bb_count) - max_src_bb_cnt = node->max_bb_count; + if (bb->count > max_src_bb_cnt) + max_src_bb_cnt = bb->count; } f_max = (double) max_value * REG_BR_PROB_BASE / max_src_bb_cnt - 1;