This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 04/10/2012 09:35 AM, Richard Sandiford wrote:
Hi Vlad,

Back in Decemember, when we were still very much in stage 3, I sent
an RFC about an alternative implementation of -fsched-pressure.
Just wanted to send a reminder now that we're in the proper stage:

http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01684.html

Ulrich has benchmarked it on ARM, S/390 and Power7 (thanks), and got
reasonable results.  (I mentioned bad Power 7 results in that message,
because of the way the VSX_REGS class is handled.  Ulrich's results
are without -mvsx though.)

The condition I orignally set myself was that this patch should only
go in if it becomes the default on at least one architecture,
specifically ARM.  Ulrich tells me that Linaro have now made it
the default for ARM in their GCC 4.7 release, so hopefully Ramana
would be OK with doing the same in upstream 4.8.

I realise the whole thing is probably more complicated and ad-hoc
than you'd like.  Saying it can't go in is a perfectly acceptable
answer IMO.

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

On the other hand, I don't think that 1st insn scheduling will be ever used for x86. And although the SPECFP2000 rate is the same on x86-64 I saw that some SPECFP2000 tests benefit from your algorithm on x86-64 (one amazing difference is 70% improvement on swim on x86-64 although it might be because of different reasons like alignment or cache behaviour). So I think the algorithm might work better on processors with more registers.

I gues it is ok to sumbit this work to the trunk. It may be useful for achieving better performance for specific tests or to make it a default for some targets if it is proven to be better.

As for the patch itself, I think you should document the option in doc/invoke.texi. It is missed. Another minor mistake I found is one line garbage (I guess from -fira-algorithm) in description of -fsched-pressure-algorithm in common.opt.

Thanks, Richard.

By the way, the code in scheduler has been changed since you made a patch and you need to do some merging first.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]