public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "law at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/109549] [14 Regression] cmov6.c test fail after commit r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
Date: Wed, 19 Apr 2023 13:37:36 +0000	[thread overview]
Message-ID: <bug-109549-4-dog5IKBuBO@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-109549-4@http.gcc.gnu.org/bugzilla/>

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-04-19

--- Comment #5 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Yea, that's exactly what's kicking in here.  The converted sequence looks like
this:

(insn 29 0 28 (set (reg:SI 86)
        (const_int 10 [0xa])) 83 {*movsi_internal}
     (nil))

(insn 28 29 30 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg/v:SI 83 [ c ])
            (const_int 0 [0]))) 7 {*cmpsi_ccno_1}
     (nil))

(insn 30 28 32 (set (reg/v:SI 85 [ e ])
        (if_then_else:SI (eq (reg:CCZ 17 flags)
                (const_int 0 [0]))
            (reg/v:SI 85 [ e ])
            (reg:SI 86))) 1318 {*movsicc_noc}
     (nil))

(insn 32 30 31 (set (reg:SI 87)
        (const_int 20 [0x14])) 83 {*movsi_internal}
     (nil))

(insn 31 32 33 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg/v:SI 83 [ c ])
            (const_int 0 [0]))) 7 {*cmpsi_ccno_1}
     (nil))

(insn 33 31 0 (set (reg/v:SI 84 [ d ])
        (if_then_else:SI (ne (reg:CCZ 17 flags)
                (const_int 0 [0]))
            (reg/v:SI 84 [ d ])
            (reg:SI 87))) 1318 {*movsicc_noc}
     (nil))


Note the two movsicc_* patterns.

So the question now is what to do about it.  It looks like things are behaving
as expected, so my first inclination would be to adjust the test.  Actually
splitting it into two would likely be even better.  One would verify that by
default we do not generate a pair of cmovs for this code, the other would turn
the tuning bit off and verify that we do generate the pair of cmovs.

Happy to do whatever the x86 maintainers want here.

  parent reply	other threads:[~2023-04-19 13:37 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-19  6:27 [Bug target/109549] New: " haochen.jiang at intel dot com
2023-04-19  6:37 ` [Bug target/109549] " pinskia at gcc dot gnu.org
2023-04-19  6:38 ` pinskia at gcc dot gnu.org
2023-04-19  7:59 ` rguenth at gcc dot gnu.org
2023-04-19  8:10 ` jakub at gcc dot gnu.org
2023-04-19 13:06 ` law at gcc dot gnu.org
2023-04-19 13:37 ` law at gcc dot gnu.org [this message]
2023-04-19 15:29 ` law at gcc dot gnu.org
2023-04-20  9:50 ` ubizjak at gmail dot com
2023-04-21 18:24 ` [Bug testsuite/109549] " cvs-commit at gcc dot gnu.org
2023-04-29 14:09 ` [Bug testsuite/109549] [14 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a law at gcc dot gnu.org
2024-01-12 10:25 ` rguenth at gcc dot gnu.org
2024-01-12 10:26 ` rguenth at gcc dot gnu.org
2024-01-15 13:50 ` rguenth at gcc dot gnu.org
2024-03-01 12:18 ` stefansf at linux dot ibm.com
2024-03-08 22:16 ` law at gcc dot gnu.org
2024-03-23  9:33 ` sjames at gcc dot gnu.org
2024-03-25  7:07 ` stefansf at linux dot ibm.com
2024-03-25  9:23 ` sjames at gcc dot gnu.org
2024-03-25 11:02 ` stefansf at gcc dot gnu.org
2024-05-07  7:40 ` [Bug testsuite/109549] [14/15 " rguenth at gcc dot gnu.org
2024-05-08  7:48 ` cvs-commit at gcc dot gnu.org
2024-05-08  7:51 ` lingling.kong7 at gmail dot com
2024-05-23  6:44 ` cvs-commit at gcc dot gnu.org
2024-05-24  1:44 ` sjames at gcc dot gnu.org
2024-06-17  6:53 ` cvs-commit at gcc dot gnu.org
2024-06-17  7:06 ` stefansf at gcc dot gnu.org
2024-06-17  7:10 ` stefansf 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-109549-4-dog5IKBuBO@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).