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 Sat, Nov 22, 2014 at 10:49 AM, Eric Botcazou ebotca...@adacore.com 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
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 November 22, 2014 12:24:22 PM CET, Eric Botcazou ebotca...@adacore.com
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
On Sat, Nov 22, 2014 at 7:38 PM, Richard Biener
richard.guent...@gmail.com wrote:
On November 22, 2014 12:24:22 PM CET, Eric Botcazou ebotca...@adacore.com
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
PING.
200 currently looks optimal for x86.
Let's commit the following:
2014-11-21 Evgeny Stupachenko evstu...@gmail.com
* 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
On Fri, Nov 21, 2014 at 11:46 AM, Evgeny Stupachenko evstu...@gmail.com wrote:
PING.
200 currently looks optimal for x86.
Let's commit the following:
2014-11-21 Evgeny Stupachenko evstu...@gmail.com
* config/i386/i386.c (ix86_option_override_internal): Increase
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%
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,
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 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
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 evstu...@gmail.com wrote:
I've measured spec2000, spec2006 as well and EEMBC for Silvermont in addition.
100-120 change gives gain
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 experienced
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 ebotca...@adacore.com wrote:
Agreed, I think the value of 100 was set decade ago by Zdenek and
On Tue, Oct 28, 2014 at 1:07 PM, Evgeny Stupachenko evstu...@gmail.com wrote:
make check for gcc passed
On Mon, Oct 27, 2014 at 11:10 AM, Evgeny Stupachenko evstu...@gmail.com
wrote:
The results are the same for Silvermont.
There are no significant changes on Haswell.
So I agree with
On Tue, Oct 28, 2014 at 1:07 PM, Evgeny Stupachenko evstu...@gmail.com
wrote:
make check for gcc passed
On Mon, Oct 27, 2014 at 11:10 AM, Evgeny Stupachenko evstu...@gmail.com
wrote:
The results are the same for Silvermont.
There are no significant changes on Haswell.
So I agree
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 hubi...@ucw.cz wrote:
On Tue, Oct 28, 2014 at 1:07 PM,
make check for gcc passed
On Mon, Oct 27, 2014 at 11:10 AM, Evgeny Stupachenko evstu...@gmail.com 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
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 evstu...@gmail.com
* config/i386/i386.c
On Fri, Oct 10, 2014 at 5:40 PM, Evgeny Stupachenko evstu...@gmail.com 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
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
richard.guent...@gmail.com wrote:
On Fri, Oct 10, 2014 at 5:40 PM, Evgeny Stupachenko evstu...@gmail.com
wrote:
Hi,
The patch
On Fri, Oct 10, 2014 at 5:40 PM, Evgeny Stupachenko evstu...@gmail.com
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
22 matches
Mail list logo
