This is the mail archive of the
mailing list for the GCC project.
Re: RFC reminder: an alternative -fsched-pressure implementation
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Vladimir Makarov <vmakarov at redhat dot com>
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>, gcc-patches at gcc dot gnu dot org, Andreas dot Krebbel at de dot ibm dot com
- Date: Tue, 24 Apr 2012 19:55:03 +0100
- Subject: Re: RFC reminder: an alternative -fsched-pressure implementation
- References: <201204231542.q3NFgwhl006805@d06av02.portsmouth.uk.ibm.com> <4F958C1C.email@example.com>
Vladimir Makarov <firstname.lastname@example.org> writes:
> On 04/23/2012 11:42 AM, Ulrich Weigand wrote:
>> Vladimir Makarov wrote:
>>> I have a mixed feeling with the patch. I've tried it on SPEC2000 on
>>> x86/x86-64 and ARM. Model algorithm generates bigger code up to 3.5%
>>> (SPECFP on x86), 2% (SPECFP on 86-64), and 0.23% (SPECFP on ARM) in
>>> comparison with the current algorithm. It is slower too. Although
>>> the difference is quite insignificant on Corei7, compiler speed
>>> slowdown achieves 0.4% on SPECFP2000 on arm. The algorithm also
>>> generates slower code on x86 (1.5% on SPECINT and 5% on SPECFP200)
>>> and practically the same average code on x86-64 and ARM (I've tried
>>> only SPECINT on ARM).
>> Was this using NEON on ARM? The biggest benefits we saw involved
>> vector code ...
> Sorry, No.
>>> On 04/17/2012 04:29 AM, Richard Sandiford wrote:
>>>> Anyway, given those results and your mixed feelings, I think it would
>>>> be best to drop the patch. It's a lot of code to carry around, and its
>>>> ad-hoc nature would make it hard to change in future. There must be
>>>> better ways of achieving the same thing.
>>> It is up to you, Richard. I don't mind if you commit it into the trunk.
>>> There is something in your approach too. If it would be possible to get
>>> the best of the two methods, we could see a big improvement.
>> On s390, the patch is pretty much a straight improvement across the line:
>> 0.5% on SPECint, 1.7% on SPECfp overall, with the best single improvement
>> in GemsFDTD (9.3%), and no regression beyond usual noise levels.
> That is a really big improvement.
>> Given that, and the impressive improvements we saw on some ARM benchmarks
>> involving vector code (up to 70%), it would really be a pity to see the
>> patch going nowhere ...
>> Is there anything we can do to help make the patch more acceptable?
>> Any suggestions welcome ...
> I did not object the patch. As I wrote Richard, it is up to him to
> decide to commit the patch or not (it still is). I had mixed results on
> x86-64 -- some better and some worse (but with average the same) with
> pretty big variations. Those big variations mean that people could use
> this for fine-tuning their programs.
> Taking your results for S390 and ARM with Neon into account, I guess it
> should be included and probably made by default for these 2 targets (for
> sure for s390).
OK, thanks to both of you.
Ulrich and Andreas: would you be happy for s390 to use this by default?
I'll update the patch and install if so.