public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: HAO CHEN GUI <guihaoc@linux.ibm.com>
To: gcc-patches <gcc-patches@gcc.gnu.org>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
	David <dje.gcc@gmail.com>, Peter Bergner <bergner@linux.ibm.com>,
	"Kewen.Lin" <linkw@linux.ibm.com>
Subject: [PATCH] Change the behavior of predicate check failure on cbranchcc4 operand0 in prepare_cmp_insn
Date: Wed, 23 Nov 2022 10:54:42 +0800	[thread overview]
Message-ID: <4a052a62-7861-ed6f-9801-3b58ac384f81@linux.ibm.com> (raw)

Hi,
  I want to enable "have_cbranchcc4" on rs6000. But not all combinations of
comparison codes and sub CC modes are benefited to generate cbranchcc4 insns
on rs6000. There is an predicate for operand0 of cbranchcc4 to bypass
some combinations. It gets assertion failure in prepare_cmp_insn. I think
we shouldn't suppose that all comparison codes and sub CC modes are supported
and throw an assertion failure in prepare_cmp_insn. It might check the
predicate and go to fail if the predicate can't be satisfied. This patch
changes the behavior of those codes.

  Bootstrapped and tested on powerpc64-linux BE/LE and x86 with no regressions.
Is this okay for trunk? Any recommendations? Thanks a lot.


ChangeLog
2022-11-23  Haochen Gui <guihaoc@linux.ibm.com>

gcc/
	* optabs.cc (prepare_cmp_insn): Go to fail other than assert it when
	predicate check of "cbranchcc4" operand[0] fails.

patch.diff
diff --git a/gcc/optabs.cc b/gcc/optabs.cc
index 165f8d1fa22..3ec8f6b17ba 100644
--- a/gcc/optabs.cc
+++ b/gcc/optabs.cc
@@ -4484,8 +4484,9 @@ prepare_cmp_insn (rtx x, rtx y, enum rtx_code comparison, rtx size,
     {
       enum insn_code icode = optab_handler (cbranch_optab, CCmode);
       test = gen_rtx_fmt_ee (comparison, VOIDmode, x, y);
-      gcc_assert (icode != CODE_FOR_nothing
-                  && insn_operand_matches (icode, 0, test));
+      gcc_assert (icode != CODE_FOR_nothing);
+      if (!insn_operand_matches (icode, 0, test))
+	goto fail;
       *ptest = test;
       return;
     }

             reply	other threads:[~2022-11-23  2:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-23  2:54 HAO CHEN GUI [this message]
2022-11-28  5:32 ` Ping " HAO CHEN GUI
2022-11-28  8:42   ` Richard Biener
2022-11-28 17:56     ` Segher Boessenkool
2022-11-28 18:46       ` Richard Biener
2022-11-28 23:02         ` Segher Boessenkool
2022-11-29  1:15         ` HAO CHEN GUI
2022-11-29  8:26           ` Richard Biener
2022-11-28  6:16 ` Kewen.Lin

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=4a052a62-7861-ed6f-9801-3b58ac384f81@linux.ibm.com \
    --to=guihaoc@linux.ibm.com \
    --cc=bergner@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=linkw@linux.ibm.com \
    --cc=segher@kernel.crashing.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).