Re: Live range shrinkage in pre-reload scheduling

[Richard Sandiford <rdsandiford at googlemail dot com>]

Vladimir Makarov <vmakarov@redhat.com> writes:
> On 2014-05-13, 6:27 AM, Kyrill Tkachov wrote:
>> Hi all,
>>
>> In haifa-sched.c (in rank_for_schedule) I notice that live range
>> shrinkage is not performed when SCHED_PRESSURE_MODEL is used and the
>> comment mentions that it results in much worse code.
>>
>> Could anyone elaborate on this? Was it just empirically noticed on x86_64?
>>
>
> It was empirically noticed on SPEC2000.  The practice is a single 
> criteria for heuristic optimizations.  Sometimes a new heuristic 
> optimization might look promising but the reality might be quite different.

Hey, I resent that.  You make it sound I came up with SCHED_PRESSURE_MODEL
on a whim without any evidence to back it up.  I implemented it because
it gave better EEMBC results on ARM, at least at the time that I wrote
it, and it didn't effect SPEC2000 for ARM much one way or the other.
It also produced better results for s390x on SPEC2006 at the time it
was tested, which is why it was turned on by default there too.

For anyone interested in the background and rationale, the original
posting was here: https://gcc.gnu.org/ml/gcc-patches/2011-12/msg01684.html

I'm not claiming it's a great heuristic or anything.  There's bound to
be room for improvement.  But it was based on "reality" and real results.

Of course, if it turns out not be a win for ARM or s390x any more then it
should be disabled.

> In this relation I am remembering a story told me by Bob Morgan about 
> bin packing RA invention.  It was just a quick and simple first RA 
> implementation for a new compiler.  After that DEC compiler team tried 
> many times to improve the RA implementing more complicated optimizations 
> but the first bin packing RA was always better.

You make it sound like your original -fsched-pressure is unlikely
to be beaten, in the way that you think bin packing wasn't beaten.
But both versions of -fsched-pressure are off by default on most
targets for a reason.  (AFAIK the only two targets that enable it by
default are the two that use SCHED_PRESSURE_MODEL: arm and s390x.)
I think this is still an area that could be improved.  I don't mind
whether that's through improving one of the two existing heuristics
or doing something different, but it seems pessimistic to say that
scheduling based on register pressure is always going to be the optional
feature that it is now.

E.g. tracking pressure classes isn't always the right thing for
targets like PowerPC where only part of the vector register set
can be used for floating-point operations.

Thanks,
Richard