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/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d w/ mtune=skylake
Date: Mon, 29 Aug 2022 10:05:57 +0000	[thread overview]
Message-ID: <bug-106590-4-8ZMSJa23Xi@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-106590-4@http.gcc.gnu.org/bugzilla/>

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

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

https://gcc.gnu.org/g:030063c43f30a2335d3c03182df0beb82d003816

commit r12-8720-g030063c43f30a2335d3c03182df0beb82d003816
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Aug 15 13:56:57 2022 +0200

    ifcvt: Fix up noce_convert_multiple_sets [PR106590]

    The following testcase is miscompiled on x86_64-linux.
    The problem is in the noce_convert_multiple_sets optimization.
    We essentially have:
    if (g == 1)
      {
        g = 1;
        f = 23;
      }
    else
      {
        g = 2;
        f = 20;
      }
    and for each insn try to create a conditional move sequence.
    There is code to detect overlap with the regs used in the condition
    and the destinations, so we actually try to construct:
    tmp_g = g == 1 ? 1 : 2;
    f = g == 1 ? 23 : 20;
    g = tmp_g;
    which is fine.  But, we actually try to create two different
    conditional move sequences in each case, seq1 with the whole
    (eq (reg/v:HI 82 [ g ]) (const_int 1 [0x1]))
    condition and seq2 with cc_cmp
    (eq (reg:CCZ 17 flags) (const_int 0 [0]))
    to rely on the earlier present comparison.  In each case, we
    compare the rtx costs and choose the cheaper sequence (seq1 if both
    have the same cost).
    The problem is that with the skylake tuning,
    tmp_g = g == 1 ? 1 : 2;
    is actually expanded as
    tmp_g = (g == 1) + 1;
    in seq1 (which clobbers (reg 17 flags)) and as a cmov in seq2
    (which doesn't).  The tuning says both have the same cost, so we
    pick seq1.  Next we check sequences for
    f = g == 1 ? 23 : 20; and here the seq2 cmov is cheaper, but it
    uses (reg 17 flags) which has been clobbered earlier.

    The following patch fixes that by detecting if we in the chosen
    sequence clobber some register mentioned in cc_cmp or rev_cc_cmp,
    and if yes, arranges for only seq1 (i.e. sequences that emit the
    comparison itself) to be used after that.

    2022-08-15  Jakub Jelinek  <jakub@redhat.com>

            PR rtl-optimization/106590
            * ifcvt.cc (check_for_cc_cmp_clobbers): New function.
            (noce_convert_multiple_sets_1): If SEQ sets or clobbers any regs
            mentioned in cc_cmp or rev_cc_cmp, don't consider seq2 for any
            further conditional moves.

            * gcc.dg/torture/pr106590.c: New test.

    (cherry picked from commit 3a74a7bf62f47ed0d19866576378724be932ee17)

  parent reply	other threads:[~2022-08-29 10:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-12  4:23 [Bug target/106590] New: x86-64 miscompilation starting with "i386: Improve ix86_expand_int_movcc" " andres at anarazel dot de
2022-08-12  4:23 ` [Bug target/106590] " andres at anarazel dot de
2022-08-12  4:37 ` [Bug target/106590] [12/13 Regression] " pinskia at gcc dot gnu.org
2022-08-12  4:38 ` pinskia at gcc dot gnu.org
2022-08-12  4:52 ` [Bug rtl-optimization/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d " pinskia at gcc dot gnu.org
2022-08-12  4:53 ` pinskia at gcc dot gnu.org
2022-08-12  4:59 ` pinskia at gcc dot gnu.org
2022-08-12  6:40 ` rguenth at gcc dot gnu.org
2022-08-12 13:47 ` jakub at gcc dot gnu.org
2022-08-12 14:46 ` jakub at gcc dot gnu.org
2022-08-15 11:57 ` cvs-commit at gcc dot gnu.org
2022-08-15 12:00 ` jakub at gcc dot gnu.org
2022-08-29 10:05 ` cvs-commit at gcc dot gnu.org [this message]
2022-08-30  9:11 ` jakub 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-106590-4-8ZMSJa23Xi@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).