From: Stafford Horne <shorne@gmail.com>
To: GCC patches <gcc-patches@gcc.gnu.org>
Cc: Linux OpenRISC <linux-openrisc@vger.kernel.org>
Subject: Re: [PATCH] or1k: Fix ICE in libgcc caused by recent validate_subreg changes
Date: Thu, 12 Jun 2025 17:28:44 +0100 [thread overview]
Message-ID: <aEsAPJzXb-pTzBD6@antec> (raw)
In-Reply-To: <20250609185946.1538314-1-shorne@gmail.com>
On Mon, Jun 09, 2025 at 07:59:46PM +0100, Stafford Horne wrote:
> After commit eb2ea476db2 ("emit-rtl: Allow extra checks for
> paradoxical subregs [PR119966]") paradoxical subregs or the OpenRISC
> condition flag register (reg:BI sr_f) are no longer allowed.
>
> This causes and ICE in the ce1 pass which tries to get the or1k flag
> register into an SI register, which is no longer possible.
>
> Adjust or1k_can_change_mode_class to allow changing the or1k flag reg to
> SI mode which in turn allows paradoxical subregs to bre generated again.
>
> gcc/ChangeLog:
>
> PR or1k/120587
> * config/or1k/or1k.cc (or1k_can_change_mode_class): Allow
> changing flags mode from BI to SI to allow for paradoxical
> subregs.
> ---
> Sending again to correct mailing list.
>
> gcc/config/or1k/or1k.cc | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/or1k/or1k.cc b/gcc/config/or1k/or1k.cc
> index 62e2168e0ee..f1c92c6bf6c 100644
> --- a/gcc/config/or1k/or1k.cc
> +++ b/gcc/config/or1k/or1k.cc
> @@ -1408,8 +1408,9 @@ static bool
> or1k_can_change_mode_class (machine_mode from, machine_mode to,
> reg_class_t rclass)
> {
> + /* Allow cnoverting special flags to SI mode subregs. */
> if (rclass == FLAG_REGS)
> - return from == to;
> + return from == to || (from == BImode && to == SImode);
> return true;
> }
I have pushed this now, it restores the or1k port to be able to compile again by
providing the behavior with subreg's that we had before.
However, this did uncover an issue with how the (reg:SI SR_F_REGNUM) SR[F]
register is treated in OpenRISC. I think the backend is producing sub optimal
code that's ok because it gets discarded, but I think its preventing CE passes
from producing optimal cmov sequences. I am working to fix this by either:
1. Working withing the current contraints of treating SR[F] as BImode
2. Change SR[F] to SImode and added proper splits/etc to make it work (like sh
does)
3. Harder, convert SR[F] handing to use CC_MODE (this might work the best?)
-Stafford
next prev parent reply other threads:[~2025-06-12 16:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 18:59 [PATCH] or1k: Fix ICE in libgcc caused by recent validate_subreg changes Stafford Horne
2025-06-12 16:28 ` Stafford Horne [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-06-09 18:52 Stafford Horne
2025-06-09 18:57 ` Simon Marchi
2025-06-09 19:01 ` Stafford Horne
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=aEsAPJzXb-pTzBD6@antec \
--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