Re: Problem with scheduling multi-block regions

[law at redhat dot com]

  In message <200108201424.PAA09822@cam-mail2.cambridge.arm.com>you write:
[ ... ]
  > Now if these are in the same region, it is possible for a link to be 
  > created between the x and z insns (so that we can potentially move one of 
  > the insns into the other block).  However, if we don't move the insns and 
  > then schedule insn x to run at, say, clock tick 30, then we will set 
  > INSN_TICK(z) to 30+cost: this value will persist even when we start 
  > scheduling bb 2 with clock set back to zero.  Hence if we finally schedule 
  > insn y at clock 5, we will enable insn z with 27 stalls (if the cost of 
  > firing z after either x or y is only, say, 2).
  > 
  > I'm not entirely sure what the fix should be, perhaps someone who 
  > understands the scheduler code better than myself could comment.  Two 
  > possibilities that come to mind are:
  > 
  > 1) Search out and zero all relevant INSN_TICK entries at the start of 
  > scheduling each block; the difficulty is finding all such cases quickly.
  > 
  > 2) Modify the scheduler so that we preserve "clock" within a region; then 
  > we wouldn't have the situation where the setting of INSN_TICK from a 
  > previous block would adversely affect the current block.  This might have 
  > the added benefit of modelling inter-block stalls as well; though it's not 
  > clear if we compute enough data for this to be useful.
I suspect #2 is the better solution.