From patchwork Thu Feb 2 22:30:45 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rong Xu X-Patchwork-Id: 139243 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 7B3B5104785 for ; Fri, 3 Feb 2012 09:31:10 +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=1328826672; 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=p/y/mah LSesQnL5ojsYFXJZDEik=; b=emyFSBOIqLNZnzsp/MEiu48oKzG10RKhcnbLii6 p3YOZlVXirmjgTjm/K85LSkVi9FuRuuPxGOba9jMJ/ykRj7G3P1ZciJWzlWt3SWm 1ugZkFs2XYdFDwRLhv20LULUUEQIDTkA+BOccP1r36vF1G1ClFka4udWmm1gr7wD hZys= 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-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=rXOV3BuVcop1Bj8pdJIeHgR76oY5jtFvDPzPQ07kONi8sZDo+GpIFB+oS2Dr5/ pq2t3znvBPRv2jLz5SsZjY0S5tWSsME1FbiHKpdmyjpxEt377lo0M8UVPENnmB8N FPZB8PWTIMywZaVdKmp9c94gVBI9gZVzUl5HqiyTaJ0Fo=; Received: (qmail 27977 invoked by alias); 2 Feb 2012 22:31:05 -0000 Received: (qmail 27957 invoked by uid 22791); 2 Feb 2012 22:31:03 -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-ey0-f201.google.com (HELO mail-ey0-f201.google.com) (209.85.215.201) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 02 Feb 2012 22:30:48 +0000 Received: by eaac10 with SMTP id c10so93739eaa.2 for ; Thu, 02 Feb 2012 14:30:47 -0800 (PST) Received: by 10.213.10.131 with SMTP id p3mr399738ebp.4.1328221847681; Thu, 02 Feb 2012 14:30:47 -0800 (PST) Received: by 10.213.10.131 with SMTP id p3mr399729ebp.4.1328221847473; Thu, 02 Feb 2012 14:30:47 -0800 (PST) Received: from hpza10.eem.corp.google.com ([74.125.121.33]) by gmr-mx.google.com with ESMTPS id p15si2663908eep.3.2012.02.02.14.30.47 (version=TLSv1/SSLv3 cipher=AES128-SHA); Thu, 02 Feb 2012 14:30:47 -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 48CD2200057; Thu, 2 Feb 2012 14:30:47 -0800 (PST) Received: by rong.mtv.corp.google.com (Postfix, from userid 104659) id 556E9C214D; Thu, 2 Feb 2012 14:30:45 -0800 (PST) To: reply@codereview.appspotmail.com, davidxl@google.com, gcc-patches@gcc.gnu.org Subject: [googlg][4.6] curb the counter scaling facor in inline transform (issue5622052) Message-Id: <20120202223046.556E9C214D@rong.mtv.corp.google.com> Date: Thu, 2 Feb 2012 14:30:45 -0800 (PST) From: xur@google.com (Rong Xu) 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 curbs the counter scaling factor that causing counter overflow in inline transformation. The negavie counter triggers a later pass assertion. Tested: inertnal performance benchmarks. -Rong 2012-02-02 Rong Xu * tree-inline.c (copy_cfg_body): Curb the scaling factor to avoid counter overflow. --- This patch is available for review at http://codereview.appspot.com/5622052 Index: tree-inline.c =================================================================== --- tree-inline.c (revision 183768) +++ tree-inline.c (working copy) @@ -2198,8 +2198,49 @@ gcov_type incoming_count = 0; if (ENTRY_BLOCK_PTR_FOR_FUNCTION (src_cfun)->count) - count_scale = (REG_BR_PROB_BASE * (double)count - / ENTRY_BLOCK_PTR_FOR_FUNCTION (src_cfun)->count); + { + struct cgraph_node *node = cgraph_node (callee_fndecl); + double f_max; + gcov_type max_count_scale; + gcov_type callee_max_bb_cnt; + gcov_type max_value = ((gcov_type) 1 << ((sizeof(gcov_type) * 8) - 1)); + max_value = ~max_value; + count_scale = (REG_BR_PROB_BASE * (double)count + / ENTRY_BLOCK_PTR_FOR_FUNCTION (src_cfun)->count); + + /* Reducing the scaling factor when it can cause counter overflow. + This can happen for comdat functions where the counters are split. + It's more likely for recursive inlines. */ + gcc_assert (node); + callee_max_bb_cnt = node->max_bb_count; + + if (callee_max_bb_cnt == 0) + { + gcov_type c = ENTRY_BLOCK_PTR_FOR_FUNCTION (src_cfun)->count; + + FOR_EACH_BB_FN (bb, src_cfun) + if (bb->count > node->max_bb_count) + callee_max_bb_cnt = node->max_bb_count; + + if (c > callee_max_bb_cnt) + callee_max_bb_cnt = c; + + node->max_bb_count = callee_max_bb_cnt; + } + + f_max = (double) max_value * REG_BR_PROB_BASE / callee_max_bb_cnt - 1; + if (f_max > max_value) + max_count_scale = max_value; + else + max_count_scale = f_max; + + if (count_scale > max_count_scale) + { + if (flag_opt_info >= OPT_INFO_MED) + warning (0, "Reducing scaling factor to avoid counter overflow."); + count_scale = max_count_scale; + } + } else count_scale = REG_BR_PROB_BASE; @@ -2221,7 +2262,7 @@ incoming_frequency += EDGE_FREQUENCY (e); incoming_count += e->count; } - incoming_count = incoming_count * count_scale / REG_BR_PROB_BASE; + incoming_count = ((double) incoming_count) * count_scale / REG_BR_PROB_BASE; incoming_frequency = incoming_frequency * frequency_scale / REG_BR_PROB_BASE; ENTRY_BLOCK_PTR->count = incoming_count;