From: "Roger Sayle" <roger@nextmovesoftware.com>
To: "'YunQiang Su'" <syq@gcc.gnu.org>
Cc: "'Jeff Law'" <jeffreyalaw@gmail.com>, <gcc-patches@gcc.gnu.org>
Subject: RE: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for SImode
Date: Sun, 24 Dec 2023 12:24:57 -0000 [thread overview]
Message-ID: <002201da3664$364d0e20$a2e72a60$@nextmovesoftware.com> (raw)
In-Reply-To: <CAKcpw6U0WEXwaZLp7v9aia+5zAW0=X899Rb4VoiESOkZzQSb7w@mail.gmail.com>
> > > What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't
> > > actually a truncation! The output precision is first, the input
> > > precision is second. The docs explicitly state the output precision
> > > should be smaller than the input precision (which makes sense for truncation).
> > >
> > > That's where I'd start with trying to untangle this mess.
> >
> > Thanks (both) for correcting my misunderstanding.
> > At the very least might I suggest that we introduce a new
> > TRULY_NOOP_EXTENSION_MODES_P target hook that MIPS can use for this
> > purpose? It'd help reduce confusion, and keep the
> > documentation/function naming correct.
> >
>
> Yes. It is good for me.
> T_N_T_M_P is a really confusion naming.
Ignore my suggestion for a new target hook. GCC already has one.
You shouldn't be using TRULY_NOOP_TRUNCATION_MODES_P
with incorrectly ordered arguments. The correct target hook is
TARGET_MODE_REP_EXTENDED, which the MIPS backend correctly
defines via mips_mode_rep_extended.
It's MIPS definition of (and interpretation of) mips_truly_noop_truncation
that's suspect.
My latest theory is that these sign extensions should be:
(set (reg:DI) (sign_extend:DI (truncate:SI (reg:DI))))
and not
(set (reg:DI) (sign_extend:DI (subreg:SI (reg:DI))))
If the RTL optimizer's ever split this instruction the semantics of
the SUBREG intermediate are incorrect. Another (less desirable)
approach might be to use an UNSPEC.
next prev parent reply other threads:[~2023-12-24 12:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-24 0:49 Roger Sayle
2023-12-24 5:38 ` Jeff Law
2023-12-24 8:51 ` Roger Sayle
2023-12-24 9:15 ` YunQiang Su
2023-12-24 9:28 ` Andrew Pinski
2023-12-24 12:24 ` Roger Sayle [this message]
2023-12-28 18:26 ` Jeff Law
2023-12-24 8:29 ` YunQiang Su
-- strict thread matches above, loose matches on Subject: below --
2023-12-23 8:58 YunQiang Su
2023-12-23 16:51 ` Jeff Law
2023-12-23 22:46 ` YunQiang Su
2023-12-24 5:27 ` Jeff Law
2023-12-24 8:11 ` YunQiang Su
2023-12-28 18:11 ` Jeff Law
2024-01-03 23:39 ` Richard Sandiford
2024-01-09 18:49 ` Jeff Law
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='002201da3664$364d0e20$a2e72a60$@nextmovesoftware.com' \
--to=roger@nextmovesoftware.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jeffreyalaw@gmail.com \
--cc=syq@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).