From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106473 invoked by alias); 2 Jan 2018 16:37:05 -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 106464 invoked by uid 89); 2 Jan 2018 16:37:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*f:sk:3b092a1, H*f:sk:ac72901, H*f:sk:87po74e, H*i:sk:3b092a1 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 ESMTP; Tue, 02 Jan 2018 16:37:04 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 175FDC059B75; Tue, 2 Jan 2018 16:37:03 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-52.rdu2.redhat.com [10.10.112.52]) by smtp.corp.redhat.com (Postfix) with ESMTP id 473DD5C1A1; Tue, 2 Jan 2018 16:37:01 +0000 (UTC) Subject: Re: [PATCH] Change PRED_LOOP_EXIT from 85 to 92 To: =?UTF-8?Q?Martin_Li=c5=a1ka?= , Segher Boessenkool , David Esparza , gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org References: <20171222225347.18748-1-david.esparza.borquez@intel.com> <20171223220816.GG10515@gate.crashing.org> <87po74ebfr.fsf@linaro.org> <20171224120327.GH10515@gate.crashing.org> <3b092a1d-6057-1ab1-82f1-26feddd1bb80@suse.cz> From: Jeff Law Message-ID: Date: Tue, 02 Jan 2018 16:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <3b092a1d-6057-1ab1-82f1-26feddd1bb80@suse.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00052.txt.bz2 On 01/02/2018 04:57 AM, Martin Liška wrote: > On 12/24/2017 07:58 PM, Jeff Law wrote: >> On 12/24/2017 05:03 AM, Segher Boessenkool wrote: >>> On Sun, Dec 24, 2017 at 09:12:56AM +0000, Richard Sandiford wrote: >>>> Segher Boessenkool writes: >>>>> On Fri, Dec 22, 2017 at 04:53:47PM -0600, David Esparza wrote: >>>>>> With a value of 85 GCC has a CPU performance degradation of 11%, >>>>>> reverting PRED_LOOP_EXIT to 92 this degradation disappear. >>>>>> Those values where measured by running c-ray ray-tracer that is a >>>>>> floating point benchmark that runs out of L1 cache. >>>>> >>>>> Why is this single benchmark more important than everything else? >>>>> >>>>> https://patchwork.ozlabs.org/patch/637073/ >>>> >>>> "Everything" else? :-) It sounds from Andrew's reply like it wasn't >>>> a win on other benchmarks too. >>> >>> Yeah... But at least Martin tested spec2006, instead of one single >>> tiny non-representative program. >>> >>>> Neither covering message has really explained why the previous value was >>>> too low/high, but maybe that's just the way it goes with these tuning >>>> parameters... >>> >>> It would be nice if they explained how they tested things. >> Agreed. I can't see any way for this patch to go forward without some >> explanation of why it helps this particular c-ray implementation and >> some data showing it's not hurtful on a wider suite of benchmarks. >> >> >> Jeff >> > > Hello. > > Sorry for late answer. I've been currently working on returning of predictors > according to SPEC2006 and SPE2017. I've got prepared patches and currently testing > it's impact on speed of SPEC benchmarks. > > From what I've measured, suggested adjustment for this particular predictor would be > increase to 89. > > Note that this predictor has quite high coverage on SPEC: 5.3% (of all branching). Understood. I think using SPEC to guide here makes much more sense. Jeff