mbox series

[0/4] Addressing modulo-scheduling bugs

Message ID fc9f9b2cbbf4051707f9c606ab7cddce@ispras.ru
Headers show
Series Addressing modulo-scheduling bugs | expand

Message

Roman Zhuykov April 16, 2019, 11:53 a.m. UTC
Last few days I’ve added my comments/patches into almost all 
modulo-scheduler PRs appeared in the last two years.  Here I want to 
discuss five PRs.  First of all, I have four patches which fix 
regressions, so technically I can ask about applying them right now on 
stage4.  But we don’t have a maintainer in modulo-sched pass, so not 
sure about their fast approval.

Last one PR90040 is meta-bug I’ve created.  It consolidates 5-6 other 
bugzilla PRs, which really are about the same issue.  Unfortunately, I 
can’t solve that myself.  Jakub, Honza, would you kindly help me and 
take a look at that PR to provide any suggestions you might have.

All my patches were successfully bootstrapped and regtested on x86_64.  
Also I’ve checked that in cross-compiler mode to s390, spu, aarch64, 
arm, ia64, ppc and ppc64 regtest shows no new regressions.  The same 
testing was done with -fmodulo-sched enabled.  Also the same testing was 
done with -fmodulo-sched -fmodulo-sched-allow-regmoves enabled.  
Moreover, all that was also done on 8 branch. No new issues introduced.  
So, since I’ve made really heavy testing,
IMO all 4 fixes can go into trunk and even 8 branch.

When development goes into stage1 and after somehow fixing PR90040 issue 
I will introduce updated patchset described here:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01647.html
(the set is supported locally on all branches since 4.9 with making a 
lot of regtesting).

Regarding the modulo scheduling maintainership, if my patches look good, 
I'm happy to volunteer to maintain the code as I looked at the code a 
lot during recent years.  Please let me know the steps I should do to 
make that happen.

Roman

Comments

Roman Zhuykov April 22, 2019, 4:45 p.m. UTC | #1
As a freshly appointed maintainer I’m ready to commit my own 
modulo-sched patches, but decide to ask here if there are any 
objections.  Maybe I should ask any additional approval at this stage?  
If no, I’ll start tomorrow with committing patches 1/4 and 2/4 which are 
well-formed regression fixes.  Patch 3/4 doesn’t include test example, 
and I don’t know how to add it there, so I am ready to postpone it to 
stage 1.  Patch 4/4 is not solving a regression technically.

First two patches can be also committed into 8 branch.  If no discussion 
occurs,  I’ll commit them later this week, e.g. on friday.

Roman
Jeff Law April 26, 2019, 3:42 p.m. UTC | #2
On 4/22/19 10:45 AM, Roman Zhuykov wrote:
> As a freshly appointed maintainer I’m ready to commit my own
> modulo-sched patches, but decide to ask here if there are any
> objections.  Maybe I should ask any additional approval at this stage? 
> If no, I’ll start tomorrow with committing patches 1/4 and 2/4 which are
> well-formed regression fixes.  Patch 3/4 doesn’t include test example,
> and I don’t know how to add it there, so I am ready to postpone it to
> stage 1.  Patch 4/4 is not solving a regression technically.
> 
> First two patches can be also committed into 8 branch.  If no discussion
> occurs,  I’ll commit them later this week, e.g. on friday.
As a maintainer we trust you to make these decisions.  Though if you
want guidance, mine would have been to go with #1 and #2 immediately and
postpone #3 and #4 for gcc-10.  THat appears to be precisely what you've
done.

Jeff
Roman Zhuykov April 26, 2019, 4:39 p.m. UTC | #3
Hello, Jeff

> > As a freshly appointed maintainer I’m ready to commit my own
> > modulo-sched patches, but decide to ask here if there are any
> > objections.  Maybe I should ask any additional approval at this stage?
> > If no, I’ll start tomorrow with committing patches 1/4 and 2/4 which are
> > well-formed regression fixes.  Patch 3/4 doesn’t include test example,
> > and I don’t know how to add it there, so I am ready to postpone it to
> > stage 1.  Patch 4/4 is not solving a regression technically.
> >
> > First two patches can be also committed into 8 branch.  If no discussion
> > occurs,  I’ll commit them later this week, e.g. on friday.
> As a maintainer we trust you to make these decisions.  Though if you
> want guidance, mine would have been to go with #1 and #2 immediately and
> postpone #3 and #4 for gcc-10.  THat appears to be precisely what you've
> done.

Thanks! I was afraid a bit to make something wrong in soon-frozing code.
Certainly Alex and Andrey help me with my first maintainter steps :)
Few minutes ago I've backported #1 and #2 into 8-branch as r270609.


Roman