Re: issues with first scheduling pass on SH4

[Vladimir Makarov <vmakarov at redhat dot com>]

"Sanjiv Kumar Gupta, Noida" wrote:
> 
> This is related to my earlier message,
> http://gcc.gnu.org/ml/gcc/2003-04/msg01454.html
> "Sanjiv Kumar Gupta, Noida" wrote:
> >> One solution to this could be to allow the instruction scheduling
> >> pass estimate the splits which will be performed later. Maybe add a new
> >> attribute to instructions indicating the number of insns generated
> >> later, and this value is examined
> >> by the scheduler during the first scheduling pass.
> 
> >I think it is the simplest solution.  As I understand analogous approach
> >is already used for some processors (like athlon/opteron).
> 
> I've experimented with this and this seems to be okay.
> 
> >> #2.
> >> The spill can be avoided by rematerialization of stack
> >> based addresses
> >> [...]
> 
> >You could try other heuristics, e.g. when the register pressure is
> >small, use critical path length as the highest priority heuristic.  When
> >the pressure achieved some threshold, make decreasing register pressure
> >heuristic as the highest one.
> 
> >Vlad
> 
> I am planning to use something like INSN_REG_WEIGHT
> to keep a count of register pressure. When this reaches
> a threshold, check if an insn which reduces the register pressure
> can be selected from the ready queue (R). If there is no such insn
> in the ready queue then probably such an insn can be
> selected from the stalled queue (Q), because in some cases it is
> cheaper to take a few stalls than spilling e.g DFmode values for
> SH.
> Please let me know your thoughts on this.

  It is hard to say what the result you could have.  Back back end
optimizations are all about heuristics.  So the single way is to try it
and get the results for benchmarks.

  Several months ago I tried to use the 1st insn scheduling to decrease
register pressure for p4 (the highest priority heuristic was always one
decreasing register pressure).  I thought that it could have decreased
registers spills (insn scheduling itself is less important for p4
because it is a well balanced OO/speculative execution processor).  But
the result was disappointed because I did not see the improvement for
SPECINT benchmarks.

Vlad