From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19372 invoked by alias); 2 Oct 2014 18:34:40 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 19356 invoked by uid 89); 2 Oct 2014 18:34:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 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; Thu, 02 Oct 2014 18:34:37 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s92IYaA1011239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 2 Oct 2014 14:34:36 -0400 Received: from stumpy.slc.redhat.com ([10.3.113.17]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s92IYYXf031002; Thu, 2 Oct 2014 14:34:35 -0400 Message-ID: <542D9ABA.8040203@redhat.com> Date: Thu, 02 Oct 2014 18:34:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Teresa Johnson , Christophe Lyon CC: Sebastian Pop , "gcc-patches@gcc.gnu.org" , Jan Hubicka , David Li Subject: Re: [PATCH] Redesign jump threading profile updates References: <53CF1DFD.7080805@redhat.com> <542A32AB.1040708@redhat.com> <20141001152256.GA24862@f1.c.bardezibar.internal> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00222.txt.bz2 On 10/01/14 14:04, Teresa Johnson wrote: > The block frequencies are very small in this case leading to rounding > errors when computing the edge frequency. The rounding error was then > propagated into the recomputed probabilities, leading to insanities in > the outgoing edge probabilities on the jump threading path. Eventually > during rtl expansion these insanities somehow caused an ICE. > > (Before this patch the probabilities weren't even being updated, > leading to insanities in other cases where they needed to be updated.) > > Specifically, in this case we had a block with frequency = 1. It had > two outgoing edges each with probability 50%. Because the > EDGE_FREQUENCY computation uses a rounding divide, the outgoing edge > frequencies were both computed as 1. Later use of these block and edge > frequencies to recompute the probability lead to both outgoing edges > getting 100%. > > To address this, in the routine freqs_to_counts_path can simply scale > up the frequencies when recording them in the count field. I added a > scale by REG_BR_PROB_BASE. The largest count possible would therefore > be REG_BR_PROB_BASE * BB_FREQ_MAX which is 10000 * 10000 = 100mil > which safely fits in gcov_type. > > Here is the patch I am testing. Confirmed it fixes the reported issue. > Currently bootstrapping and testing on x86_64-unknown-linux-gnu. Ok > for trunk if it passes? > > (The whitespace is getting messed up when I copy the patch in here - > the indentations do line up in the patch.) > > Thanks, > Teresa > > 2014-10-01 Teresa Johnson > > * tree-ssa-threadupdate.c (freqs_to_counts_path): Scale frequencies > up when synthesizing counts to avoid rounding errors. OK. jeff