Selective scheduling and its usage

Selective scheduling and its usage

[Martin Liška]

Hello.

I noticed there are quite many selective scheduling PRs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659

and many others.

I want to ask you if you plan to maintain the scheduling?
Is it enabled by default for any target we support?
Should we deprecate it for GCC 8?

Thank you,
Martin

Re: Selective scheduling and its usage

[Andrey Belevantsev]

Hi Martin,

On 21.03.2018 12:48, Martin Liška wrote:
> Hello.
> 
> I noticed there are quite many selective scheduling PRs:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659
> 
> and many others.
> 
> I want to ask you if you plan to maintain the scheduling?

Yes.  The current status is that I have patches for 83530, 83962, 83913,
83480, 83972, 80463.  I don't have patches for any of the 84* issues.
I'm planning to submit the patches for the former set and to look at the
later set next week.

I usually do most of the work by myself after internal discussions with
Alexander and other colleagues here, and there might be delays when I get
busy with unrelated stuff.  However, if there's a pressing need, we have
enough knowledgeable people to fix any sel-sched PR within a week or so.

> Is it enabled by default for any target we support?

Yes, ia64 at -O3.  The testing we make usually is like follows: bootstrap
and test on ia64, bootstrap with sel-sched enabled on x86-64, and make any
new tests from PRs be run on x86-64, ia64, and ppc.  This way I'm confident
that it mostly works on that platforms.

> Should we deprecate it for GCC 8?

No, I don't think so.

Best,
Andrey

> 
> Thank you,
> Martin

Re: Selective scheduling and its usage

[Martin Liška]

On 03/21/2018 11:17 AM, Andrey Belevantsev wrote:
> Hi Martin,
> 
> On 21.03.2018 12:48, Martin Liška wrote:
>> Hello.
>>
>> I noticed there are quite many selective scheduling PRs:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659
>>
>> and many others.
>>
>> I want to ask you if you plan to maintain the scheduling?
> 
> Yes.  The current status is that I have patches for 83530, 83962, 83913,
> 83480, 83972, 80463.  I don't have patches for any of the 84* issues.
> I'm planning to submit the patches for the former set and to look at the
> later set next week.

Nice!

Maybe we can create a meta bug to track all sel. scheduling issue.
May I create it?

> 
> I usually do most of the work by myself after internal discussions with
> Alexander and other colleagues here, and there might be delays when I get
> busy with unrelated stuff.  However, if there's a pressing need, we have
> enough knowledgeable people to fix any sel-sched PR within a week or so.
> 
>> Is it enabled by default for any target we support?
> 
> Yes, ia64 at -O3.  The testing we make usually is like follows: bootstrap
> and test on ia64, bootstrap with sel-sched enabled on x86-64, and make any
> new tests from PRs be run on x86-64, ia64, and ppc.  This way I'm confident
> that it mostly works on that platforms.

Great.

> 
>> Should we deprecate it for GCC 8?
> 
> No, I don't think so.

Works for me.

Thanks for clarification.
Martin

> 
> Best,
> Andrey
> 
>>
>> Thank you,
>> Martin
> 

Re: Selective scheduling and its usage

[Andrey Belevantsev]

On 21.03.2018 13:31, Martin Liška wrote:
> On 03/21/2018 11:17 AM, Andrey Belevantsev wrote:
>> Hi Martin,
>>
>> On 21.03.2018 12:48, Martin Liška wrote:
>>> Hello.
>>>
>>> I noticed there are quite many selective scheduling PRs:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659
>>>
>>> and many others.
>>>
>>> I want to ask you if you plan to maintain the scheduling?
>>
>> Yes.  The current status is that I have patches for 83530, 83962, 83913,
>> 83480, 83972, 80463.  I don't have patches for any of the 84* issues.
>> I'm planning to submit the patches for the former set and to look at the
>> later set next week.
> 
> Nice!
> 
> Maybe we can create a meta bug to track all sel. scheduling issue.
> May I create it?

Yes, of course.  I would be happy because I can easily lose track (I have
some queries in Bugzilla about scheduling but I don't monitor whole
gcc-bugs traffic).  In fact, I wasn't aware of some PR from your list until
your mail.

Best,
Andrey

> 
>>
>> I usually do most of the work by myself after internal discussions with
>> Alexander and other colleagues here, and there might be delays when I get
>> busy with unrelated stuff.  However, if there's a pressing need, we have
>> enough knowledgeable people to fix any sel-sched PR within a week or so.
>>
>>> Is it enabled by default for any target we support?
>>
>> Yes, ia64 at -O3.  The testing we make usually is like follows: bootstrap
>> and test on ia64, bootstrap with sel-sched enabled on x86-64, and make any
>> new tests from PRs be run on x86-64, ia64, and ppc.  This way I'm confident
>> that it mostly works on that platforms.
> 
> Great.
> 
>>
>>> Should we deprecate it for GCC 8?
>>
>> No, I don't think so.
> 
> Works for me.
> 
> Thanks for clarification.
> Martin
> 
>>
>> Best,
>> Andrey
>>
>>>
>>> Thank you,
>>> Martin
>>
> 

Re: Selective scheduling and its usage

[Eric Botcazou]

> I noticed there are quite many selective scheduling PRs:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659
> 
> and many others.

Right, and some of them are P1/P2, which doesn't really make sense IMO.

-- 
Eric Botcazou

Re: Selective scheduling and its usage

[Richard Biener]

On Thu, Mar 29, 2018 at 12:15 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> I noticed there are quite many selective scheduling PRs:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659
>>
>> and many others.
>
> Right, and some of them are P1/P2, which doesn't really make sense IMO.

Are you suggesting we should not care about regressions with features
that are not enabled by default or which are only exposed with "non-standard"
flags?  The current scheme on which bugs get P1/P2/P4+ assigned is
quite simple...

Richard.

> --
> Eric Botcazou

Re: Selective scheduling and its usage

[Jeff Law]

On 03/29/2018 04:15 AM, Eric Botcazou wrote:
>> I noticed there are quite many selective scheduling PRs:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659
>>
>> and many others.
> 
> Right, and some of them are P1/P2, which doesn't really make sense IMO.
I'm  of the opinion we should deprecate the selective scheduler.  IA64
is a don't care and while it works on other targets, I don't think it's
getting significant use in the wild -- and it's a significant
maintenance burden release to release.

I haven't pushed much on it because I'm slammed with a ton of other
stuff, but I just don't see that selective-scheduling on the right side
of the cost/benefit analysis.

jeff

Re: Selective scheduling and its usage

[Eric Botcazou]

> Are you suggesting we should not care about regressions with features
> that are not enabled by default or which are only exposed with
> "non-standard" flags?  The current scheme on which bugs get P1/P2/P4+
> assigned is quite simple...

I'm only suggesting keeping them at P3, which is not "don't care" as far as I 
know but just the default priority.  The criterion could be a flag that is not 
part of any -Ox switches and not enabled on any primary+secondary platforms.

-- 
Eric Botcazou

Re: Selective scheduling and its usage

[Richard Biener]

On March 29, 2018 5:14:42 PM GMT+02:00, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> Are you suggesting we should not care about regressions with features
>> that are not enabled by default or which are only exposed with
>> "non-standard" flags?  The current scheme on which bugs get P1/P2/P4+
>> assigned is quite simple...
>
>I'm only suggesting keeping them at P3, which is not "don't care" as
>far as I 
>know but just the default priority.  The criterion could be a flag that
>is not 
>part of any -Ox switches and not enabled on any primary+secondary
>platforms.

That's basically having primary / secondary / rest passes (or command line switches) which we would need to document as such. Let's discuss this at the Cauldron - I'm certainly not going to block the release over a selective scheduling bug...

Richard.