Vladimir Makarov wrote:
Steven Bosscher wrote:
On Wed, Apr 8, 2009 at 5:19 AM, Vladimir Makarov <vmaka...@redhat.com>
wrote:
I've been working on register-pressure sensitive insn scheduling last
two
months and I hope to submit this work for gcc4.5. I am implementing
also a
mode in insn-scheduler to do only live range shrinkage.
Is all of this still necessary if the selective scheduler (with
register renaming) is made to work on i686/x86_64 after reload?
That is a really interesting question, Steven. I thought about
this for a few months (since last fall). Here is my points to result
me in starting my work on haifa-scheduler:
1. Selective scheduler works only for Itanium now. As I know there
are some plans to make it working on PPC, but there are no plans
to make it working for other acrhictectures for now.
There are some patches for fixing sel-sched on PPC that I need to ping,
thanks for reminding me :) They were too late for regression-only
mode, and we didn't get access to modern PPCs as we hoped, so this was
not an issue earlier. Btw, when we've submitted the scheduler, it did
work on x86-64 (compile farm), I don't know whether this is still the case.
2. My understanding is that (register-pressure sensitive insn
scheduling + RA + 2nd insn scheduling) is not equal to (RA +
selective scheduling with register renaming) with the point of
the potential performance results. In first case, the
pressure-sensitive insn scheduler could improve RA by live-range
shrinkage. In the 2nd case it is already impossible. It could
be improved by the 2nd RA but RA is more time consuming than
scheduling now. In general this chicken-egg problem could be
solved by iterating the 2 contradictory passes insn scheduling +
RA (or RA + insns scheduling). It is a matter of practicality
when to stop these iterations.
3. My current understanding is that selective scheduler is overkill
for architectures with few registers. In other words, I don't
think it will give a better performance for such architectures.
On the other hand, it is much slower than haifa-scheduler because
of its complexity. Haifa-scheduler before RA already adds 3-5% compile
time, selective scheduler will add 5-7% more compile time without
performance improvement for mainstream architectures x86/x86_64.
I think it is intolerable.
We still plan to do some speedups to the sel-sched code within 4.5
timeframe, mainly to the dependence handling code. But even after that,
I agree that for out-of-order architectures selective scheduler will
probably be an overkill. Besides, register renaming itself would remain
an expensive operation, because it needs to scan all paths along which
an insn was moved to prove that the new register can be used, though we
have invested a lot of time for speeding up this process via various
caching mechanisms. On ia64, register renaming is useful for pipelining
loops.
Also, we have tried to limit register renaming for the 1st pass
selective scheduler via tracking register pressure and having a cutoff
for that, but it didn't work out very well on ia64, so I agree that much
more of RA knowledge should be brought in for this task.
Hope this helps. Vlad, Steven, thanks for caring.
Andrey
