From: zhroma <zhroma@ispras.ru>
To: gcc-patches@gcc.gnu.org
Cc: gcc@gcc.gnu.org, Jakub Jelinek <jakub@redhat.com>,
Jan Hubicka <hubicka@ucw.cz>
Subject: [0/4] Addressing modulo-scheduling bugs
Date: Tue, 16 Apr 2019 11:59:00 -0000 [thread overview]
Message-ID: <fc9f9b2cbbf4051707f9c606ab7cddce@ispras.ru> (raw)
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
next reply other threads:[~2019-04-16 11:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-16 11:59 zhroma [this message]
2019-04-16 12:03 ` [1/4][PATCH] Fix PR84032 Roman Zhuykov
2019-04-16 12:05 ` [2/4][PATCH] Fix PR87979 Roman Zhuykov
2019-04-16 12:08 ` [3/4][PATCH] Fix PR90001 Roman Zhuykov
2019-04-26 15:42 ` Jeff Law
2019-04-26 17:41 ` Roman Zhuykov
2019-04-16 12:26 ` [4/4][PATCH] Discussing PR83507 Roman Zhuykov
2019-04-16 15:10 ` Segher Boessenkool
2019-04-22 16:45 ` Roman Zhuykov
2019-04-23 15:55 ` Segher Boessenkool
2019-04-29 16:56 ` Roman Zhuykov
2019-04-29 17:51 ` Segher Boessenkool
2019-04-30 11:35 ` Roman Zhuykov
2019-04-30 15:14 ` Jeff Law
2019-04-22 19:16 ` [0/4] Addressing modulo-scheduling bugs Roman Zhuykov
2019-04-26 15:45 ` Jeff Law
2019-04-26 16:41 ` Roman Zhuykov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fc9f9b2cbbf4051707f9c606ab7cddce@ispras.ru \
--to=zhroma@ispras.ru \
--cc=gcc-patches@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=jakub@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).