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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

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

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

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

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com