Re: issues with first scheduling pass on SH4

["Vladimir N. Makarov" <vmakarov at redhat dot com>]

"Sanjiv Kumar Gupta, Noida" wrote:

> So, the overall idea I came up with for reducing the register
> pressure in 1st scheduling is as:
>
> INSN_REG_WEIGHT does NOT differntiate between
> reg_classes while calculating the reg_weight.i.e The
> INSN_REG_WEIGHT is zero if the dying
> register is of a different class than the register born. Thus
> from the cumulative INSN_REG_WEIGHTs of scheduled insns, we can
> not get a picture of the register pressure on a particular
> reg_class.
> So,I will have to write some code that can estimate the reg_weight of an
> insn for specified reg_classes. A target can enable this
> estimation code by specifying the reg_classes of its interest.
> The insn weights for target specified reg_classes will be calculated
> and stored into a dynamically allocated two dimensional array.
>
> Once this information is in place, target reordering hooks
> can calculate the current register pressure
> for a particular reg_class due to already scheduled insns.
> And if the pressure on a reg_class is *high*, they can reorder the ready
> queue to reduce the pressure for that reg_class.
>
> Vlad, I will be happy to get your comments/suggestions on this.

As for idea of taking register pressure into account during insn
scheduling, I already wrote my comment in
http://gcc.gnu.org/ml/gcc/2003-07/msg00231.html.  In general, it could work
to improve the code.  But what kind improvement you could get, I don't
know.  As I wrote, more simple approach did not work for p4.

As for detail of the implementation I see the following difficulties:

1. Register pressure (register liveness) is based on CFG.  You could start
calculation of register pressure in BB being scheduled from the registers
lived at the BB start.  Unfortunately, this information is invalidated by
moving insns from another block (interblock insn moving made during the 1st
insn scheduling).  I don't know how to update this information quickly.

2. Two register classes (see regclass.c) can be assigned to a
pseudoregister.  Interaction of the two classes can be quite different.
They might be intersected or not.  One class can be subset of another
class.  It makes difficult to calculate the register pressure accurately
for each register class because it is hard to say what register class will
be used finally for the pseudoregister.  But you could use worst scenario
at the first time.

3. The biggest problem is reload.  It likes a block box, it is hard to say
how it will behave.  E.g. it could do register coalescing and register
materialization (see REG_EQUIV notes with constant), change register on
memory.  It can considerably invalidate the calculated register pressure.
You could take the reload behaviour into account too which can complicate
the implementation.

So it is hard to say, what the final result you will have.  But this is a
usual way for a new optimization.

Good luck.

Vlad