Maxim Kuvyrkov wrote:
Hi.
I want to share some of my thoughts and doings on improving / cleaning
up current GCC instruction scheduler (Haifa) - most of them are just
small obvious improvements.
I have semi-ready patches for about a half of them and would appreciate
any early suggestion or comments on the following draft plan:
1. Remove compute_forward_dependencies (). [Done]
2. Use alloc_pools instead of obstacks for dep_nodes and deps_lists.
[In progress]
3. Define clear interface for manipulating dependencies. [In progress]
4. Support speculative loads into subregs. [Planned]
5. Make sched-deps.c mark only those dependencies as speculative which
can actually be overcame with speculation types currently in use.
[Planned]
6. Make ds_t a structure. [Planned]
7. Use cse_lib in sched-rgn.c . [In progress]
8. Don't generate a memory barrier on simplejump. [Done]
9. Use sched-ebb on other architectures. [Done]
10. Leveled priority. [Done]
11. Implement control speculation in sched-ebb. [In progress]
12. Initialize scheduler data structures for each region separately and
index them by luid. [Done]
13. Generate regions from extended basic blocks in sched-rgn.c [Planned]
14. Some sort of must alias analysis for scheduler. [Planned]
Any comments, suggestions or 'please don't do that' will be greatly
appreciated.
It sounds as a good and interesting plan. I have no serious objection
to any of these proposals. Cleaning scheduler code is definitely plan
to go. I like idea for using ebb scheduler as the 2nd scheduler. As
for proposed different heuristics, only benchmarking will say that but
it is a good thing to try them in any case.
Good aliasing is very important for the scheduler. But I'd look at this
more wider. We need a good aliasing for many RTL optimizations. What's
happened to ISP RAS aliasing patch propagating SSA info to RTL? Why is
it stalled?
As for Sanjiv Gupta's aliasing work, that was interesting but as I
remember the patch made compiler too slow (like 40% slower). You should
make this approach faster to make it accepted as used by default.
Another important thing to do is to make the 1st scheduler register
pressure sensitive. It would improve performance and solve the 1st insn
scheduling problem for x86, x86_64. Now it is off by default because
the scheduler moves insns containing hard regs too freely and this
results in failure of the reload to find a hard register of a small class.
If you need benchmarking for machines (like ppc) you have no access to,
I can provide the benchmarking.
I should also mention that I do all these works in my spare time which
is not a lot, thus the above is my plan for about a half of the year.
I really appreciate. May be if you or ISP RAS could find students (e.g.
from Moscow University) to do this as Google Summer Code, it could help
you. I think it is not too late. You should ask Ian Taylor or Daniel
Berlin, if you want to do this.
