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.
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.
I think problems #1 and #2 could be resolved by investing
significant resources. I don't think problem #3 could be resolved.
I'd like to be wrong and will accept this if somebody shows me. But
they will need my implementation of register-pressure sensitive insn
scheduler in any case to prove it.
Although I'd wish to see one insn-scheduler as many other people,
now I believe that haifa-scheduler and selective scheduler (by the way
they share a lot of common code) will coexist. One could be used for
architectures with few registers and another one for architectures
with massive fine-grain parallelism which needs a lot of explicit
registers. We could still remove EBB insn scheduler because selective
scheduler works much better.
I hope I answered your question which is difficult for me because I
always supported selective-scheduling project and really wanted to
see it as a single insn scheduler.
