Linux OpenRISC platform development
 help / color / mirror / Atom feed
From: Stafford Horne <shorne@gmail.com>
To: GCC patches <gcc-patches@gcc.gnu.org>
Cc: Linux OpenRISC <linux-openrisc@vger.kernel.org>,
	Stafford Horne <shorne@gmail.com>
Subject: [PATCH] or1k: Stop allowing referring to SR_F in SImode and fix cmov
Date: Mon,  6 Jul 2026 06:53:14 +0100	[thread overview]
Message-ID: <20260706055314.1428104-1-shorne@gmail.com> (raw)

We were seeing compiler errors such as:

    x.c:8:1: error: insn does not satisfy its constraints:
	8 | }
	  | ^
    (insn 33 28 35 2 (set (reg:SI 34 ?sr_f)
	    (reg:SI 16 r17 [52])) "x.c":6:7 discrim 1 28 {*movsi_internal}
	 (nil))
    during RTL pass: postreload

This was being caused by previous commit c0694f95f59 ("or1k: Fix ICE in
libgcc caused by recent validate_subreg changes") and commit 710581c80b2
("or1k: Allow SImode for condition flag register") which allow
referecing SR_F in SImode to avoid errors during if conversion.

We can completely avoid this by reverting the changes to allow
referencing SR_F in SImode and fixing the
or1k_noce_conversion_profitable_p function to allow cmov expansion even
when TARGET_CMOV is not enabled.  The *cmov split logic can take care of
lowering the *cmov instructions if l.cmov is not supported during the
later split passes.

gcc/

	PR target/126081
	* config/or1k/or1k.cc (or1k_hard_regno_mode_ok): Stop allowing
	SImode for FLAG_REGS.
	(or1k_can_change_mode_class): Stop allowing SImode for
	FLAG_REGS.
	(or1k_noce_conversion_profitable_p): Always check
	or1k_is_cmov_insn.

gcc/testsuite/

	PR target/126081
	* gcc.target/or1k/pr126081.c: New test.
---
THis has been tested with toolchain and rootfs builds as well as the GCC
testsuite with no regressions.  After message reviews I will push.

 gcc/config/or1k/or1k.cc                  | 14 ++++++++------
 gcc/testsuite/gcc.target/or1k/pr126081.c |  8 ++++++++
 2 files changed, 16 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/or1k/pr126081.c

diff --git a/gcc/config/or1k/or1k.cc b/gcc/config/or1k/or1k.cc
index f1ecf21c6e2..89076ae02fc 100644
--- a/gcc/config/or1k/or1k.cc
+++ b/gcc/config/or1k/or1k.cc
@@ -1393,7 +1393,7 @@ or1k_hard_regno_mode_ok (unsigned int regno, machine_mode mode)
      really single bits within SP[SR].  Also allow condition flag register
      in SImode to match or1k_can_change_mode_class.  */
   if (REGNO_REG_CLASS (regno) == FLAG_REGS)
-    return mode == BImode || mode == SImode;
+    return mode == BImode;
   return true;
 }
 
@@ -1411,7 +1411,7 @@ or1k_can_change_mode_class (machine_mode from, machine_mode to,
 {
   /* Allow cnoverting special flags to SI mode subregs.  */
   if (rclass == FLAG_REGS)
-    return from == to || (from == BImode && to == SImode);
+    return from == to;
   return true;
 }
 
@@ -1697,15 +1697,17 @@ or1k_is_cmov_insn (rtx_insn *seq)
 }
 
 /* Implement TARGET_NOCE_CONVERSION_PROFITABLE_P.  We detect if the conversion
-   resulted in a l.cmov instruction and if so we consider it more profitable than
-   branch instructions.  */
+   resulted in a l.cmov like instruction and if so we consider it more
+   profitable than branch instructions.  Even if we do not support l.cmov this
+   allows the *cmov instruction sequnce to be expanded and then later lowered
+   with the *cmov split logic.  */
 
 static bool
 or1k_noce_conversion_profitable_p (rtx_insn *seq,
 				    struct noce_if_info *if_info)
 {
-  if (TARGET_CMOV)
-    return or1k_is_cmov_insn (seq);
+  if (or1k_is_cmov_insn (seq))
+    return true;
 
   return default_noce_conversion_profitable_p (seq, if_info);
 }
diff --git a/gcc/testsuite/gcc.target/or1k/pr126081.c b/gcc/testsuite/gcc.target/or1k/pr126081.c
new file mode 100644
index 00000000000..b5cce62f3e9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/or1k/pr126081.c
@@ -0,0 +1,8 @@
+int option_mask32;
+void xsocket(int);
+enum { OPT_u = 1 << 3 };
+
+void nc_main() {
+  int x = option_mask32 & OPT_u ? 2 : 1;
+  xsocket(x);
+}
-- 
2.53.0


                 reply	other threads:[~2026-07-06  5:53 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20260706055314.1428104-1-shorne@gmail.com \
    --to=shorne@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=linux-openrisc@vger.kernel.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