From: Segher Boessenkool <segher@kernel.crashing.org>
To: Roger Sayle <roger@nextmovesoftware.com>
Cc: "'GCC Patches'" <gcc-patches@gcc.gnu.org>,
"'Tamar Christina'" <tnfchris@gcc.gnu.org>
Subject: Re: [PATCH] PR rtl-optimization/106594: Preserve zero_extend when cheap.
Date: Mon, 12 Sep 2022 11:47:47 -0500 [thread overview]
Message-ID: <20220912164747.GW25951@gate.crashing.org> (raw)
In-Reply-To: <007201d8c637$e2c3bfd0$a84b3f70$@nextmovesoftware.com>
Hi!
On Mon, Sep 12, 2022 at 12:40:31AM +0100, Roger Sayle wrote:
> * gcc/combine.cc (expand_compound_operation): Don't expand/transform
> ZERO_EXTEND or SIGN_EXTEND on targets where rtx_cost claims they are
> cheap. If gen_lowpart returns a SUBREG of something other than a
> REG or a MEM, i.e. invalid RTL, return the original expression.
This needs testing and analysis on all platforms.
> @@ -7309,7 +7319,11 @@ expand_compound_operation (rtx x)
> if (modewidth >= pos + len)
> {
> tem = gen_lowpart (mode, XEXP (x, 0));
> - if (!tem || GET_CODE (tem) == CLOBBER)
> + if (!tem
> + || GET_CODE (tem) == CLOBBER
> + || (GET_CODE (tem) == SUBREG
> + && !REG_P (SUBREG_REG (tem))
> + && !MEM_P (SUBREG_REG (tem))))
> return x;
Why handle subregs of memory here? Those are antiquated, and should go
away pretty soon.
All of {expand,make}_compound_operation should be removed. But this is
non-trivial work. All of {SIGN,ZERO}_EXTRACT should be eradicated as
well, in my opinion.
Segher
next prev parent reply other threads:[~2022-09-12 16:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-11 23:40 Roger Sayle
2022-09-12 10:31 ` Richard Sandiford
2022-09-12 14:16 ` Roger Sayle
2022-09-12 14:56 ` Richard Sandiford
2022-09-12 16:47 ` Segher Boessenkool [this message]
2022-09-12 18:09 ` Segher Boessenkool
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=20220912164747.GW25951@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=roger@nextmovesoftware.com \
--cc=tnfchris@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).