public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/99863] [10 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
Date: Tue, 20 Apr 2021 09:45:42 +0000	[thread overview]
Message-ID: <bug-99863-4-2KkJeT30R0@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-99863-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:7a2f91d413eb7a3eb0ba52c7ac9618a35addd12a

commit r10-9721-g7a2f91d413eb7a3eb0ba52c7ac9618a35addd12a
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Apr 3 10:07:09 2021 +0200

    dse: Fix up hard reg conflict checking in replace_read [PR99863]

    Since PR37922 fix RTL DSE has hard register conflict checking
    in replace_read, so that if the replacement sequence sets (or typically
just
    clobbers) some hard register (usually condition codes) we verify that
    hard register is not live.
    Unfortunately, it compares the hard reg set clobbered/set by the sequence
    (regs_set) against the currently live hard register set, but it then
    emits the insn sequence not at the current insn position, but before
    store_insn->insn.
    So, we should not compare against the current live hard register set,
    but against the hard register live set at the point of the store insn.
    Fortunately, we already have that remembered in
store_insn->fixed_regs_live.

    In addition to bootstrapping/regtesting this patch on x86_64-linux and
    i686-linux, I've also added statistics gathering and it seems the only
    place where we end up rejecting the replace_read is the newly added
    testcase (the PR37922 is no longer effective at that) and fixed_regs_live
    has been always non-NULL at the if (store_insn->fixed_regs_live) spot.
    Rather than having there an assert, I chose to just keep regs_set
    as is, which means in that hypothetical case where fixed_regs_live wouldn't
    be computed for some store we'd still accept sequences that don't
    clobber/set any hard registers and just punt on those that clobber/set
    those.

    2021-04-03  Jakub Jelinek  <jakub@redhat.com>

            PR rtl-optimization/99863
            * dse.c (replace_read): Drop regs_live argument.  Instead of
            regs_live, use store_insn->fixed_regs_live if non-NULL,
            otherwise punt if insns sequence clobbers or sets any hard
            registers.

            * gcc.target/i386/pr99863.c: New test.

    (cherry picked from commit 9c7473688e78dc41fd4312a983453df195dd7786)

  parent reply	other threads:[~2021-04-20  9:45 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01  8:44 [Bug target/99863] New: [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 zsojka at seznam dot cz
2021-04-01  9:01 ` [Bug target/99863] " rguenth at gcc dot gnu.org
2021-04-01  9:14 ` rguenth at gcc dot gnu.org
2021-04-01  9:58 ` rguenth at gcc dot gnu.org
2021-04-01 10:02 ` [Bug target/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba marxin at gcc dot gnu.org
2021-04-01 10:24 ` rguenth at gcc dot gnu.org
2021-04-01 10:45 ` [Bug rtl-optimization/99863] " rguenth at gcc dot gnu.org
2021-04-01 10:47 ` cvs-commit at gcc dot gnu.org
2021-04-01 11:16 ` ebotcazou at gcc dot gnu.org
2021-04-01 11:28 ` ebotcazou at gcc dot gnu.org
2021-04-01 12:26 ` jakub at gcc dot gnu.org
2021-04-01 12:45 ` rguenther at suse dot de
2021-04-01 13:01 ` jakub at gcc dot gnu.org
2021-04-01 13:23 ` jakub at gcc dot gnu.org
2021-04-01 13:27 ` jakub at gcc dot gnu.org
2021-04-01 13:32 ` rguenther at suse dot de
2021-04-01 13:35 ` jakub at gcc dot gnu.org
2021-04-01 13:54 ` jakub at gcc dot gnu.org
2021-04-03  8:07 ` cvs-commit at gcc dot gnu.org
2021-04-03  8:16 ` [Bug rtl-optimization/99863] [10 " jakub at gcc dot gnu.org
2021-04-08 12:02 ` rguenth at gcc dot gnu.org
2021-04-20  9:45 ` cvs-commit at gcc dot gnu.org [this message]
2021-04-20  9:50 ` jakub at gcc dot gnu.org
2021-04-20 23:34 ` cvs-commit at gcc dot gnu.org
2021-04-22 16:52 ` cvs-commit 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-99863-4-2KkJeT30R0@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).