This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Change PRED_LOOP_EXIT from 85 to 92
- From: Jeff Law <law at redhat dot com>
- To: Martin Liška <mliska at suse dot cz>, Segher Boessenkool <segher at kernel dot crashing dot org>, David Esparza <david dot esparza dot borquez at intel dot com>, gcc-patches at gcc dot gnu dot org, richard dot sandiford at linaro dot org
- Date: Tue, 2 Jan 2018 09:36:59 -0700
- Subject: Re: [PATCH] Change PRED_LOOP_EXIT from 85 to 92
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <20171223220816.GG10515@gate.crashing.org> <email@example.com> <20171224120327.GH10515@gate.crashing.org> <firstname.lastname@example.org> <email@example.com>
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 <firstname.lastname@example.org> 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?
>>>> "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
>>> 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.
> 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.