Re: Remove sel-sched?

[Andrey Belevantsev <abel at ispras dot ru>]

On 14.01.2016 20:26, Jeff Law wrote:
> On 01/14/2016 12:07 AM, Andrey Belevantsev wrote:
> > Hello Bernd,
> >
> > 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.
> > >
> > > Thoughts?
> >
> > 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
> > for that.
> >
> > 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 :)

Andrey

> Jeff