This is the mail archive of the
mailing list for the GCC project.
Re: Remove sel-sched?
- From: Andrey Belevantsev <abel at ispras dot ru>
- To: Jeff Law <law at redhat dot com>, Bernd Schmidt <bschmidt at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 15 Jan 2016 12:48:31 +0300
- Subject: Re: Remove sel-sched?
- Authentication-results: sourceware.org; auth=none
- References: <569696A5 dot 9000204 at redhat dot com> <56974947 dot 3060004 at ispras dot ru> <5697DA29 dot 3090404 at redhat dot com>
On 14.01.2016 20:26, Jeff Law wrote:
On 01/14/2016 12:07 AM, Andrey Belevantsev wrote:
On 13.01.2016 21:25, Bernd Schmidt wrote:
There are a few open PRs involving sel-sched, and I'd like to start a
discussion about removing it. Having two separate schedulers isn't a very
good idea in the first place IMO, and since ia64 is dead, sel-sched gets
practically no testing despite being the more complex one.
Out of the PRs we have, two are actually fixed but not marked as such.
This year's PRs are from the recent Zdenek's Debian rebuild with GCC 6
and I will be on them now. For the other two last year PRs, it is my
fault not to fix them in a timely manner. Frankly, 2015 was very tough
for me and my colleagues (we worked 6 days a week most part of the
year), but since January it is fine again and we'll catch up now. Sorry
You're also right that sel-sched now gets limited testing. We're made
it work initially for ia64, x64, ppc and cell, and then added ARM, too.
Outside of ia64 world, I had private reports of sel-sched being used for
cell with success, and we used it in our own contractor work for
optimizing some ARM apps with GCC.
In short, we're willing to maintain sel-sched and I apologize for the
slow PR fixing speed last year, it should be no problem anymore as of
now. If there are any big plans of reorganizing schedulers and
sel-sched stands in the way of those, let's discuss it and we'll be
willing to help in any way.
FWIW, I've downgraded the sel-sched stuff to P4 for this release given how
that scheduler is typically used (ia64, which is a dead platform).
I think the bigger question Bernd is asking here is whether or not it makes
sense to have multiple schedulers. In an ideal world we'd bake them off
select the best and deprecate/remove the others.
I didn't follow sel-sched development closely, so forgive me if the
questions are simplistic/naive, but what are the main benefits of sel-sched
and is it at a point (performance-wise) where it could conceivably replace
the aging haifa scheduler infrastructure?
The main sel-sched points at the time of its inclusion were as follows:
bookkeeping code support (move an insn between any blocks in the scheduling
region), insn transformations support (renaming, unification, substitution
through register copies), scheduling at several points at once, pipelining
support. Together it paid off with something like 7-8% on SPEC at the time
on ia64, but not so on the other archs, where we didn't spend much time for
tuning and usually got both ups and downs compared to haifa. On ia64 the
speedup was mostly because of pipelining with speculation, as far as I
recall, for others including ARM renaming and substitution were useful.
Since then, Vlad and Bernd put more improvements to the haifa scheduler,
including sched pressure, predication and backtracking, so both schedulers
now have features not present in the other one and the initial feature
advantage somewhat wore off.
Also, the big problem of sel-sched is speed -- it is slow because the
dependency lists are not maintained through the scheduler, most of
transformation stuff is implemented through an insn movement up the region
and looking what should happen to allow insn A move up through insn B.
I've done most of I could imagine to speed it up but haven't managed making
sel-sched by default on -O2.
So to sum this up, I don't think sel-sched can replace haifa in its current
state. These days to speed up the scheduler I'd add something like path
based dependency tracking with bit vectors like it is done in Intel's
wavefront scheduling, though it is patented (Vlad may correct me here).
Or, we need to devise other means of keeping dependencies up to date.
We've tried that but never got it working good enough.
The thing I would not like to lose is sel-sched pipelining. It can work on
any loops, not only countable ones like modulo scheduling, and this can
make a difference for some apps even outside of ia64. But if one basic
scheduler is desired, maybe the better use of our resources will be to
improve modulo scheduling instead to not lose pipelining capabilies in gcc.
It is completely unmaintained now, my colleague Roman Zhuykov had a
couple of improvements ~4yrs ago but most of them never got into trunk due
to lack of review. He can step up as a modulo-sched maintainer if needed,
the code is alive (see PR69252).
Sorry for a long mail :)