From: Jeff Law <jeffreyalaw@gmail.com>
To: YunQiang Su <syq@gcc.gnu.org>,
gcc-patches@gcc.gnu.org, pinskia@gmail.com, rguenther@suse.de,
richard.sandiford@arm.com
Subject: Re: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for SImode
Date: Tue, 9 Jan 2024 11:49:16 -0700 [thread overview]
Message-ID: <af0ef2da-3971-47f2-95a2-d775f9c01aba@gmail.com> (raw)
In-Reply-To: <mpt7ckq7zra.fsf@arm.com>
On 1/3/24 16:39, Richard Sandiford wrote:
> YunQiang Su <syq@gcc.gnu.org> writes:
>> On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
>> if 31 or above bits is polluted by an bitops, we will need an
>> truncate. Let's emit one, and mark let's use the same hardreg
>> as in and out, the RTL may like:
>>
>> (insn 21 20 24 2 (set (subreg/s/u:SI (reg/v:DI 200 [ val ]) 0)
>> (truncate:SI (reg/v:DI 200 [ val ]))) "../xx.c":7:29 -1
>> (nil))
>>
>> We use /s/u flags to mark it as really needed, as in
>> combine_simplify_rtx, this insn may be considered as truncated,
>> so let's skip this combination.
>>
>> gcc/ChangeLog:
>> PR: 104914.
>> * combine.cc (try_combine): Skip combine with truncate if
>> dest is subreg and has /u/s flags on platforms
>> TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true.
>> * expr.cc (expand_assignment): Emit a truncate insn, if
>> 31+ bits is polluted for SImode.
>>
>> gcc/testsuite/ChangeLog:
>> PR: 104914.
>> * gcc.target/mips/pr104914.c: New testcase.
>
> Sorry for not looking at this earlier. I've got a bit lost in the
> various threads, so apologies if this has been discussed already
> but I think the fix is:
>
> diff --git a/gcc/expr.cc b/gcc/expr.cc
> index 4f42c0ff487..9847eba19fe 100644
> --- a/gcc/expr.cc
> +++ b/gcc/expr.cc
> @@ -6275,9 +6275,8 @@ expand_assignment (tree to, tree from, bool nontemporal)
> else
> {
> rtx to_rtx1
> - = lowpart_subreg (subreg_unpromoted_mode (to_rtx),
> - SUBREG_REG (to_rtx),
> - subreg_promoted_mode (to_rtx));
> + = convert_to_mode (subreg_unpromoted_mode (to_rtx),
> + SUBREG_REG (to_rtx), false);
> result = store_field (to_rtx1, bitsize, bitpos,
> bitregion_start, bitregion_end,
> mode1, from, get_alias_set (to),
>
> (completely untested apart from the test case). That should still
> produce a subreg on most targets, but generates the required trunc
> on MIPS.
I think this is a subset of Roger's work that got committed a few days back.
jeff
next prev parent reply other threads:[~2024-01-09 18:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
2023-12-28 18:26 ` Jeff Law
2023-12-24 8:29 ` YunQiang Su
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=af0ef2da-3971-47f2-95a2-d775f9c01aba@gmail.com \
--to=jeffreyalaw@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=pinskia@gmail.com \
--cc=rguenther@suse.de \
--cc=richard.sandiford@arm.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).