issues with first scheduling pass on SH4

[Sanjiv Kumar Gupta, Noida]

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.

--Sanjiv




> -----Original Message-----
> From: Sanjiv Kumar Gupta, Noida 
> Sent: Tuesday, July 08, 2003 1:57 PM
> To: Dorit Naishlos; gcc@gcc.gnu.org
> Cc: vmakarov@redhat.com; dje@watson.ibm.com
> Subject: RE: issues with first scheduling pass on SH4 
> 
> 
> > 1. Added in schedule_block() a (conditional) call to a function
> > that selectively moves insns from Q to R:
> > 
> > 1- if (condition1)
> > 2-   early_queue_to_ready();
> > 
> > The above code can be inserted either (1) when R becomes empty,
> > right before giving up on scheduling additional instructions
> > in the current cycle (i.e. before line 4),
> > or (2) whenever new instructions maybe added into R,
> > before R is sorted (before lines 2 and 9).
> > 
> > The "condition1" can be, in your case, something like:
> >   (!reload_completed && INSN_REG_WEIGHT > threshold)
> > 
> This very well matches to what I was thinking to do. In
> my case, an insn which reduces the register pressure might still
> be available in the R but may not be at the head of R (i.e. may
> not be the highest priority as the priority is based on critical
> path). In that case I will simply have to reorder R to
> put that desired insn at the head of the R so that choose_ready
> can pick it.
> 
> > 2. Implemented early_queue_to_ready():
> > 
> > 1- for (insn = scan the queue in-order; ... ; ...){
> > 2   - cost <- state_transition(insn) (and other checks);
> > 3   - if (cost < 0 && ok_for_early_schedule(insn)){
> > 4     - remove insn from Q, and add it to the ready list.
> > 5     - if (condition2)
> > 6          break;
> > 7     }
> > 8   }
> > 
> > (line 2 should be identical to line 6 in schedule_block() above,
> > to avoid creating an infinite R->Q->R... loop).
> > The "ok_for_early_schedule(insn)" can check, in your case,
> > if insn reduces high register pressure.
> > The "condition2" can restrict the number of instructions removed
> > from the queue to one at a time, or more if desired.
> > [...]
> > Maybe this general scheme could fit your purposes too?
> > 
> > dorit
> > 
> Yes, this should be fine for me too.
> 
> The only problem I am currently facing is 
> how to separately estimate register pressure for
> various reg_classes like GENERAL_REGs
> and FP_REGs. INSN_REG_WEIGHT does
> distinguish between reg_classes.
> I think I will have to write macros like
> INSN_GENERAL_REG_WEIGHT, INSN_FP_REG_WEIGHT.
> 
> Sanjiv
>