public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <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: Fri, 04 Feb 2022 13:12:02 +0000	[thread overview]
Message-ID: <bug-103006-4-3Q1w0McWGg@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 #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
There's an interesting case,

  a = BIRTH
loop:
  b = DEATH
  a = DEATH
  b = BIRTH
  goto loop;

where we end up having both a and b in the live-in set at the loop label
but a is removed before we see the BIRTH of b which is where we add
conflicts based on the current set of active vars.

In the case I'm running into this I have tail-recursion do

  a = BIRTH
  b = BIRTH
...
  a = DEATH
  b = DEATH

into

loop:
  a = BIRTH
  b = BIRTH
  goto loop;
  a = DEATH
  b = DEATH

leading to a similar issue.  The issue above can for example arise from
loop rotation.

In all cases live from backedges confuse the "optimization" done to only
record conflicts when we add a var to the live set (and it is not already set).

The previous code had

              /* If this is the first real instruction in this BB we need
                 to add conflicts for everything live at this point now.
                 Unlike classical liveness for named objects we can't
                 rely on seeing a def/use of the names we're interested in.
                 There might merely be indirect loads/stores.  We'd not add any
                 conflicts for such partitions.  */

and the easiest is to do the same here (we don't see the backedge "use"),
but we could possibly improve by noting which vars are only live from
a backedge here.

  parent reply	other threads:[~2022-02-04 13:12 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
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 [this message]
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-3Q1w0McWGg@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).