Re: Reload patch to improve 386 code

[Jeffrey A Law <law@hurl.cygnus.com>]

  In message <Pine.SOL.3.90.970819094031.291D-100000@starsky.informatik.rwth-aa
chen.de>you write:
  > The idea of running sched before reload seems to be to improve code like
  > this:
  > move mem1 => pseudo1
  > move pseudo1 => mem2
  > move mem3 => pseudo2
  > move pseudo2 => mem4
  > move mem5 => pseudo3
  > move pseudo3 => mem6
Or, more generally:

  * The scheduling pass before reload has fewer data dependencies (because
  it works with pseudos), and thus can more instructions more freely to
  produce better schedules.  However, the downside is potentially increased
  register pressure.

  * The scheduling pass after reload primarily helps with scheduling of
  spill code and prologue/epilogue insns.  With pseudos mapped to hard
  registers, there are far fewer opportunities for the scheduler to
  move instructions.

  > If this is left as it stands, register allocation will most likely allocate
  > the pseudo to the same hard register. This means the post-reload sched pass
  > can't do anything with it, and the CPU can't either because there is no
  > parallelism in the code (well, at least the Pentium can't).
Yup.

  > you suddenly have two blocks of three independent instructions which could
  > run in parallel. However, this will lose badly once you don't have three
  > instructions of that kind, but a hundred (since your average CPU doesn't
  > have a hundred hard registers).
Yup.  Hence my message about throttling the scheduler once the ratio of
pseudos to hard registers hits some magic number.


  > Another approach I've been thinking about is to add code that analyzes code
  > like this after reload
  > 
  > move mem1 => hardreg1
  > move hardreg1 => mem2
  > move mem3 => hardreg1
  > move hardreg1 => mem4
  > move mem5 => hardreg1
  > move hardreg1 => mem6
  > 
  > and tries to make it use as many independent hard registers as possible.
  > That would make the scheduling opportunities available without the risk
  > of over-scheduling before reload. I don't know how feasible this is.
Yes, I've considered doing similar things myself, but I didn't think it
was really worth the effort..

Jeff
Jeff