public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "roger at nextmovesoftware dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
Date: Thu, 03 Aug 2023 09:09:12 +0000 [thread overview]
Message-ID: <bug-104914-4-zpfsKX5GPd@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-104914-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
Roger Sayle <roger at nextmovesoftware dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |roger at nextmovesoftware dot com
--- Comment #15 from Roger Sayle <roger at nextmovesoftware dot com> ---
Is MIPS64 actually a TRULY_NOOP_TRUNCATION_TARGET? If SImode is implicitly
assumed to be (sign?) extended, then an arbitrary DImode value/register can't
be used as an SImode value without appropriately setting/clearing the upper
bits.
i.e. thus this integer truncation isn't a no-op.
I suspect that the underlying problem is that the backend is relying on
implicit invariants, not explicitly represented in the RTL, and then surprised
when valid RTL transformations don't preserve those invariants/assumptions.
I wonder why the zero_extract followed by sign_extend example mentioned in
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626137.html isn't already
being considered as a try_combine candidate, allowing the backend to simply
recognize or split it. I'll investigate.
next prev parent reply other threads:[~2023-08-03 9:09 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-14 11:49 [Bug target/104914] New: " mmyangfl at gmail dot com
2022-03-14 12:13 ` [Bug target/104914] " mmyangfl at gmail dot com
2023-07-04 6:42 ` syq at gcc dot gnu.org
2023-07-04 8:33 ` syq at gcc dot gnu.org
2023-07-04 9:05 ` pinskia at gcc dot gnu.org
2023-07-04 10:14 ` syq at gcc dot gnu.org
2023-07-05 9:50 ` syq at gcc dot gnu.org
2023-07-06 19:05 ` [Bug rtl-optimization/104914] " pinskia at gcc dot gnu.org
2023-07-07 4:21 ` syq at gcc dot gnu.org
2023-07-07 4:31 ` pinskia at gcc dot gnu.org
2023-07-07 4:52 ` pinskia at gcc dot gnu.org
2023-07-07 5:05 ` pinskia at gcc dot gnu.org
2023-07-07 5:12 ` pinskia at gcc dot gnu.org
2023-07-12 2:23 ` syq at gcc dot gnu.org
2023-07-14 10:15 ` syq at gcc dot gnu.org
2023-08-03 9:09 ` roger at nextmovesoftware dot com [this message]
2023-08-03 9:34 ` syq at gcc dot gnu.org
2023-12-24 13:53 ` roger at nextmovesoftware dot com
2023-12-24 14:06 ` roger at nextmovesoftware dot com
2023-12-24 16:15 ` roger at nextmovesoftware dot com
2023-12-24 23:04 ` syq at gcc dot gnu.org
2023-12-25 1:44 ` syq at gcc dot gnu.org
2023-12-25 1:47 ` syq at gcc dot gnu.org
2023-12-27 14:02 ` syq at gcc dot gnu.org
2024-01-04 1:56 ` cvs-commit at gcc dot gnu.org
2024-01-04 10:50 ` cvs-commit at gcc dot gnu.org
2024-01-04 11:10 ` syq 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-104914-4-zpfsKX5GPd@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).