public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/103006] [9/10/11/12 Regression] wrong code at -O1 or -O2 on x86_64-linux-gnu by r7-7101
Date: Tue, 02 Nov 2021 08:10:57 +0000 [thread overview]
Message-ID: <bug-103006-4-Ny9obsO77K@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-103006-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103006
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 2 Nov 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103006
>
> --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Looks like that.
> What do you think about unrolling making variable copies? We'd need to be sure
> that the scope of the variable is the loop we are unrolling though (or
> something nested in it).
Being able to determine that would solve the very issue we're trying
to fix with making the copy. The problem is that we put in CLOBBERs
based on the original BINDs but later optimizers do not respect the
birth boundary. If we can figure that out we could ignore the
respective CLOBBERs for the CFG expansion live compute as well.
I think we may be able to compute the CFG SCC a CLOBBER resides in
and in case the CLOBBERed variable is live-in into that SCC we cannot
prune it with that CLOBBER. Or so.
next prev parent reply other threads:[~2021-11-02 8:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-30 17:45 [Bug tree-optimization/103006] New: wrong code at -O2 (only) on x86_64-linux-gnu zhendong.su at inf dot ethz.ch
2021-10-30 22:12 ` [Bug tree-optimization/103006] [9/10/11/12 Regression] " pinskia at gcc dot gnu.org
2021-10-30 22:15 ` [Bug middle-end/103006] [9/10/11/12 Regression] wrong code at -O1 or -O2 " pinskia at gcc dot gnu.org
2021-10-30 22:28 ` [Bug rtl-optimization/103006] " pinskia at gcc dot gnu.org
2021-11-01 11:13 ` [Bug rtl-optimization/103006] [9/10/11/12 Regression] wrong code at -O1 or -O2 on x86_64-linux-gnu by r7-7101 jakub at gcc dot gnu.org
2021-11-01 11:29 ` jakub at gcc dot gnu.org
2021-11-02 7:17 ` rguenth at gcc dot gnu.org
2021-11-02 7:57 ` jakub at gcc dot gnu.org
2021-11-02 8:10 ` rguenther at suse dot de [this message]
2021-11-02 8:20 ` jakub at gcc dot gnu.org
2021-11-02 13:55 ` rguenther at suse dot de
2021-11-05 13:39 ` rguenth at gcc dot gnu.org
2022-01-31 10:52 ` rguenth at gcc dot gnu.org
2022-01-31 13:01 ` rguenth at gcc dot gnu.org
2022-01-31 13:08 ` rguenth at gcc dot gnu.org
2022-02-02 11:44 ` rguenth at gcc dot gnu.org
2022-02-04 13:12 ` rguenth at gcc dot gnu.org
2022-05-27 9:46 ` [Bug rtl-optimization/103006] [10/11/12/13 " rguenth at gcc dot gnu.org
2022-06-28 10:46 ` jakub at gcc dot gnu.org
2023-07-07 10:41 ` [Bug middle-end/103006] [11/12/13/14 " rguenth at gcc dot gnu.org
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=bug-103006-4-Ny9obsO77K@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/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).