issues with first scheduling pass on SH4

["Sanjiv Kumar Gupta, Noida" <sanjivg at noida dot hcltech dot com>]

Hi,
I am trying to re-enable the first scheduling pass
for SH4. I observed the following problems while
doing this.

#1.
For code like 
	
	in [17] += in [16];
	in [16] += in [15];
	...

The scheduler tries to hide the latency of fadd by moving
other ready insns in between the fadd and result store. 
it generates something like
	
	.
	r170 = r158 + 136 	<-- address computation for store
	.
	r174 = r174 + r170;	<-- fadd
	.
	.
	[issue other ready insns for next 7 cycles]
	.
	.
	[r170] = r174		<-- store

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.

#2.
In benchmarks having multiple load/stores, the compiler is
scheduling the address computation for loads too early
than the load itself. The actual load happens much later
when all of the conflicting stores have been completed.
This creates the need to preserve the address register for load
 and causes spills.
 
Consider following RTL dump of dct64.i

Cycle    Insn    rtx
54--> 1093     r691=r14+0x78

55--> 1091     r436=r159+r436

56--> 908      {r523=r523+r541;use ;}
56--> 927      r556=r14+r556

57--> 950      r574=0xc8
57--> 1099     r424=r159+r424

58--> 972      r592=0xa8

59--> 909      {[r533]=r523;use ;clobber scratch;}
59--> 951      r574=r14+r574

60--> 917      {[r545]=r548;use ;clobber scratch;}
60--> 973      r592=r14+r592
.....
.....
.....
137--> 1094 {r692=[r691];use ;clobber scratch;}

Here, the address for a load has already been computed at
cycle 54 (insn 1093). But the actual load is happening only at cycle
137 (insn 1094). In between there are stores that may alias with
the load at 137.  The insn 1093 is ready very early and picked
by the scheduler for issue. But the actual load is not getting
 scheduled till all the aliasing stores have been scheduled. This
causes the spilling of the address register r691.

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.

--Sanjiv