From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55776 invoked by alias); 24 Dec 2017 12:03:34 -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 55765 invoked by uid 89); 24 Dec 2017 12:03:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*i:sk:87po74e, H*f:sk:87po74e X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 24 Dec 2017 12:03:32 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id vBOC3SHj028204; Sun, 24 Dec 2017 06:03:28 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id vBOC3R6K028197; Sun, 24 Dec 2017 06:03:27 -0600 Date: Sun, 24 Dec 2017 12:03:00 -0000 From: Segher Boessenkool To: David Esparza , gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Subject: Re: [PATCH] Change PRED_LOOP_EXIT from 85 to 92 Message-ID: <20171224120327.GH10515@gate.crashing.org> References: <20171222225347.18748-1-david.esparza.borquez@intel.com> <20171223220816.GG10515@gate.crashing.org> <87po74ebfr.fsf@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87po74ebfr.fsf@linaro.org> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg01511.txt.bz2 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. Segher