From patchwork Tue Jul 26 11:11:50 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Jambor X-Patchwork-Id: 106828 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 05FADB70BD for ; Tue, 26 Jul 2011 21:12:10 +1000 (EST) Received: (qmail 5293 invoked by alias); 26 Jul 2011 11:12:08 -0000 Received: (qmail 5281 invoked by uid 22791); 26 Jul 2011 11:12:07 -0000 X-SWARE-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Jul 2011 11:11:52 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 1EC398FB03; Tue, 26 Jul 2011 13:11:51 +0200 (CEST) Date: Tue, 26 Jul 2011 13:11:50 +0200 From: Martin Jambor To: GCC Patches Cc: Jan Hubicka Subject: [PATCH, PR 49786] Avoid overflow when updating counts in IPA-CP Message-ID: <20110726111150.GA20101@virgil.arch.suse.de> Mail-Followup-To: GCC Patches , Jan Hubicka MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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, the issue in PR 49786 has been well summarized in comment #12. Basically, the multiplication we do when updating counts of edges overflows. I looked at how this was handled previously in IPA-CP and the following should be an equivalent solution. This patch fixes the LTO profiled bootstrap and I have tested it by doing a usual non-LTO and non-profiled bootstrap and testsuite (without any issues) run as well as running the testsuite on the compiler produced by the LTO profiled bootstrap. I compared the second set of testsuite results with both the results obtained from a revision before the IPA-CP submission and the current normal bootstrap ones and it seemed fine (although there were a few dump scan failures). (All of the above was done on x86_64-linux.) So, OK for trunk? Thanks, Martin 2011-07-25 Martin Jambor PR bootstrap/49786 * ipa-cp.c (update_profiling_info): Avoid overflow when updating counts. (update_specialized_profile): Likewise. Index: src/gcc/ipa-cp.c =================================================================== --- src.orig/gcc/ipa-cp.c +++ src/gcc/ipa-cp.c @@ -1877,7 +1877,6 @@ dump_profile_updates (struct cgraph_node cgraph_node_name (cs->callee), (HOST_WIDE_INT) cs->count); } - /* After a specialized NEW_NODE version of ORIG_NODE has been created, update their profile information to reflect this. */ @@ -1923,12 +1922,14 @@ update_profiling_info (struct cgraph_nod for (cs = new_node->callees; cs ; cs = cs->next_callee) if (cs->frequency) - cs->count = cs->count * new_sum / orig_node_count; + cs->count = cs->count * (new_sum * REG_BR_PROB_BASE + / orig_node_count) / REG_BR_PROB_BASE; else cs->count = 0; for (cs = orig_node->callees; cs ; cs = cs->next_callee) - cs->count = cs->count * remainder / orig_node_count; + cs->count = cs->count * (remainder * REG_BR_PROB_BASE + / orig_node_count) / REG_BR_PROB_BASE; if (dump_file) dump_profile_updates (orig_node, new_node); @@ -1966,7 +1967,8 @@ update_specialized_profile (struct cgrap for (cs = orig_node->callees; cs ; cs = cs->next_callee) { - gcov_type dec = cs->count * redirected_sum / orig_node_count; + gcov_type dec = cs->count * (redirected_sum * REG_BR_PROB_BASE + / orig_node_count) / REG_BR_PROB_BASE; if (dec < cs->count) cs->count -= dec; else