Re: issues with first scheduling pass on SH4

[Vladimir Makarov <vmakarov at redhat dot com>]

"Sanjiv Kumar Gupta, Noida" wrote:
> 
> Hi,
> I am trying to re-enable the first scheduling pass
> for SH4. I observed the following problems while
> doing this.
> 
> #1.
> The problem here is, any of the insns between fadd and
> store may be loads or other insns that might split (e.g. DFmode
> load splits for SH4) into multiple insns. This further increases
> the life span of address register r170.
> 
> 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.
> Please let me know if you have better ways to handle it.
>

I think it is the simplest solution.  As I understand analogous approach
is already used for some processors (like athlon/opteron).
 
> #2.
> The spill can be avoided by rematerialization of stack
> based addresses (r691),
> but I am thinking if I could anyhow avoid the distance between
> the related insns 1093 and 1094. I am short of any ideas to solve
> this one. Please help.

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.  Or use the critical path heuristic as the
highest one but take load/store latency (for spilled register) into
account.

As I wrote, on my opinion the insn scheduler should be the last pass of
the compiler.  It'll solve the split and spilling problems.  But the
scheduler in this case should make register renaming/forward
substitution.  It is easier approach than an integrated register
allocator and insn scheduler (especially for gcc).

Vlad