From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34479 invoked by alias); 2 Jan 2018 11:57:48 -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 34470 invoked by uid 89); 2 Jan 2018 11:57:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,KAM_NUMSUBJECT,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Jan 2018 11:57:46 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 24D86AD62; Tue, 2 Jan 2018 11:57:44 +0000 (UTC) Subject: Re: [PATCH] Change PRED_LOOP_EXIT from 85 to 92 To: Jeff Law , 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> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: <3b092a1d-6057-1ab1-82f1-26feddd1bb80@suse.cz> Date: Tue, 02 Jan 2018 11:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00018.txt.bz2 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). Martin