Re: RFC reminder: an alternative -fsched-pressure implementation

[Vladimir Makarov <vmakarov at redhat dot com>]

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).