On Sat, Nov 22, 2014 at 7:38 PM, Richard Biener
wrote:
> On November 22, 2014 12:24:22 PM CET, Eric Botcazou
> wrote:
>>> Yeah, but after a couple of pings for a generic change, we went the
>>target
>>> way.
>>
>>That's a bit of a shame, the 400 -> 100 change was very likely tested
>>only on
>>x
On November 22, 2014 12:24:22 PM CET, Eric Botcazou
wrote:
>> Yeah, but after a couple of pings for a generic change, we went the
>target
>> way.
>
>That's a bit of a shame, the 400 -> 100 change was very likely tested
>only on
>x86-64 and nevetheless applied to the generic code, so the fix
>rep
> Yeah, but after a couple of pings for a generic change, we went the target
> way.
That's a bit of a shame, the 400 -> 100 change was very likely tested only on
x86-64 and nevetheless applied to the generic code, so the fix repairing the
damages should also be applied to the generic code.
--
On Sat, Nov 22, 2014 at 10:49 AM, Eric Botcazou wrote:
>> OK. Looks like a good performance vs. codesize tradeoff.
>
> Yes, but IMO this should be done in the generic code, unrolling small loops is
> profitable on most architectures.
Yeah, but after a couple of pings for a generic change, we went
> OK. Looks like a good performance vs. codesize tradeoff.
Yes, but IMO this should be done in the generic code, unrolling small loops is
profitable on most architectures.
--
Eric Botcazou
On Fri, Nov 21, 2014 at 11:46 AM, Evgeny Stupachenko wrote:
> PING.
> "200" currently looks optimal for x86.
> Let's commit the following:
>
> 2014-11-21 Evgeny Stupachenko
> * config/i386/i386.c (ix86_option_override_internal): Increase
> PARAM_MAX_COMPLETELY_PEELED_INSNS.
OK.
PING.
"200" currently looks optimal for x86.
Let's commit the following:
2014-11-21 Evgeny Stupachenko
* config/i386/i386.c (ix86_option_override_internal): Increase
PARAM_MAX_COMPLETELY_PEELED_INSNS.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 6337aa5..5
Code size for spec2000 is almost unchanged (many benchmarks have the
same binaries).
For those that are changed we have the following numbers (200 vs 100,
both dynamic build -Ofast -funroll-loops -flto):
183.equake +10%
164.gzip, 173.applu +3,5%
187.facerec, 191.fma3d +2,5%
200.sixstrack +2%
177.me
> > 150 and 200 make Silvermont performance better on 173.applu (+8%) and
> > 183.equake (+3%); Haswell spec2006 performance stays almost unchanged.
> > Higher value of 300 leave the performance of mentioned tests
> > unchanged, but add some regressions on other benchmarks.
> >
> > So I like 200 a
> 150 and 200 make Silvermont performance better on 173.applu (+8%) and
> 183.equake (+3%); Haswell spec2006 performance stays almost unchanged.
> Higher value of 300 leave the performance of mentioned tests
> unchanged, but add some regressions on other benchmarks.
>
> So I like 200 as well as 12
150 and 200 make Silvermont performance better on 173.applu (+8%) and
183.equake (+3%); Haswell spec2006 performance stays almost unchanged.
Higher value of 300 leave the performance of mentioned tests
unchanged, but add some regressions on other benchmarks.
So I like 200 as well as 120 and 150, b
So are there any objections to enable this
(PARAM_MAX_COMPLETELY_PEELED_INSNS increase from 100 to 120) for x86?
On Fri, Oct 31, 2014 at 7:52 PM, Evgeny Stupachenko wrote:
> I've measured spec2000, spec2006 as well and EEMBC for Silvermont in addition.
> 100->120 change gives gain for Silvermont,
I've measured spec2000, spec2006 as well and EEMBC for Silvermont in addition.
100->120 change gives gain for Silvermont, the results on Haswell are flat.
On Fri, Oct 31, 2014 at 3:14 PM, Eric Botcazou wrote:
>> Agreed, I think the value of 100 was set decade ago by Zdenek and me
>> completely ar
> Agreed, I think the value of 100 was set decade ago by Zdenek and me
> completely artifically. I do not recall any serious tuning of this flag.
Are you talking bout PARAM_MAX_COMPLETELY_PEELED_INSNS here? If so, see:
https://gcc.gnu.org/ml/gcc-patches/2012-11/msg01193.html
We have experience
Yes the speed up is the same. However I'm testing only x86
performance. Potentially we can somehow hurt ARM or others
performance.
GCC already has the tuning enabled for rs6000,s390, spu.
Evgeny
On Thu, Oct 30, 2014 at 8:27 PM, Jan Hubicka wrote:
>> On Tue, Oct 28, 2014 at 1:07 PM, Evgeny Stupac
> On Tue, Oct 28, 2014 at 1:07 PM, Evgeny Stupachenko
> wrote:
> > make check for gcc passed
> >
> > On Mon, Oct 27, 2014 at 11:10 AM, Evgeny Stupachenko
> > wrote:
> >> The results are the same for Silvermont.
> >> There are no significant changes on Haswell.
> >> So I agree with Richard, let'
On Tue, Oct 28, 2014 at 1:07 PM, Evgeny Stupachenko wrote:
> make check for gcc passed
>
> On Mon, Oct 27, 2014 at 11:10 AM, Evgeny Stupachenko
> wrote:
>> The results are the same for Silvermont.
>> There are no significant changes on Haswell.
>> So I agree with Richard, let's enable this x86 w
make check for gcc passed
On Mon, Oct 27, 2014 at 11:10 AM, Evgeny Stupachenko wrote:
> The results are the same for Silvermont.
> There are no significant changes on Haswell.
> So I agree with Richard, let's enable this x86 wide.
>
> Bootstrap/ passed.
> Make check in progress.
> Is it ok?
>
> 2
The results are the same for Silvermont.
There are no significant changes on Haswell.
So I agree with Richard, let's enable this x86 wide.
Bootstrap/ passed.
Make check in progress.
Is it ok?
2014-10-25 Evgeny Stupachenko
* config/i386/i386.c (ix86_option_override_internal): Increase
> On Fri, Oct 10, 2014 at 5:40 PM, Evgeny Stupachenko
> wrote:
> > Hi,
> >
> > The patch increase PARAM_MAX_COMPLETELY_PEELED_INSNS for CPUs with
> > high branch cost.
> > Bootstrap and make check are in progress.
> > The patch boosts (up to 2,5 times improve) several benchmarks compiled
> > with
I need to collect data from Haswell, but the patch should not help
it's performance much, just increase code size.
On Mon, Oct 13, 2014 at 12:01 PM, Richard Biener
wrote:
> On Fri, Oct 10, 2014 at 5:40 PM, Evgeny Stupachenko
> wrote:
>> Hi,
>>
>> The patch increase PARAM_MAX_COMPLETELY_PEELED_I
On Fri, Oct 10, 2014 at 5:40 PM, Evgeny Stupachenko wrote:
> Hi,
>
> The patch increase PARAM_MAX_COMPLETELY_PEELED_INSNS for CPUs with
> high branch cost.
> Bootstrap and make check are in progress.
> The patch boosts (up to 2,5 times improve) several benchmarks compiled
> with "-Ofast" on Silver
Hi,
The patch increase PARAM_MAX_COMPLETELY_PEELED_INSNS for CPUs with
high branch cost.
Bootstrap and make check are in progress.
The patch boosts (up to 2,5 times improve) several benchmarks compiled
with "-Ofast" on Silvermont
Spec2000:
+5% gain on 173.applu
+1% gain on 255.vortex
Is it ok for
23 matches
Mail list logo
