public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: Roger Sayle <roger@nextmovesoftware.com>,
	"'GCC Patches'" <gcc-patches@gcc.gnu.org>,
	"'Segher Boessenkool'" <segher@kernel.crashing.org>
Subject: Re: [PATCH] Fix RTL simplifications of FFS, POPCOUNT and PARITY.
Date: Mon, 2 Jan 2023 16:59:15 +0100	[thread overview]
Message-ID: <Y7L/U6+YPVeg1FKC@tucnak> (raw)
In-Reply-To: <f9ecae1e-c63b-260d-a4b7-2e8d5fb89f11@gmail.com>

On Mon, Jan 02, 2023 at 08:45:15AM -0700, Jeff Law via Gcc-patches wrote:
> On 1/1/23 08:55, Roger Sayle wrote:
> > In 2011, the rtl.texi documentation was updated to reflect that the
> > modes of the RTX unary operations FFS, POPCOUNT and PARITY must
> > match those of their operands.  Unfortunately, some of the transformations
> > in simplify-rtx.cc predate this tightening of RTL semantics, and have
> > not (until now) been updated/fixed.  i.e. The POPCOUNT and PARITY
> > optimizations were "correct" when I originally added them back in 2007.
> > 
> > Segher requested that I split this piece out from a fix for PR 106594 in
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601501.html
> > 
> > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> > and make -k check, both with and without --target_board=unix{-m32},
> > with no new failures.  Ok for mainline?
> > 
> > 
> > 2023-01-01  Roger Sayle  <roger@nextmovesoftware.com>
> > 
> > gcc/ChangeLog
> > 	* gcc/simplify-rtx.cc (simplify_unary_operation_1) <case FFS>:
> > 	Avoid generating FFS with mismatched operand and result modes, by
> > 	using an explicit SIGN_EXTEND/ZERO_EXTEND instead.
> > 	<case POPCOUNT>: Likewise, for POPCOUNT of ZERO_EXTEND.
> > 	<case PARITY>: Likewise, for PARITY of {ZERO,SIGN}_EXTEND.
> ?!?  The docs still seem to indicate to me that the modes of the input and
> output operands can differ.  Let's take PARITY as an example:

See the PR50161 thread in
https://gcc.gnu.org/legacy-ml/gcc-patches/2011-08/threads.html#01847
The options are to disallow different modes, which is what my patch did
(perhaps not all documentation has been tweaked), or ensure that the operand
of those is never constant.  The latter is much harder and needs to be done
in many places.  While for SUBREG/ZERO_EXTEND/SIGN_EXTEND and to some extend
also FLOAT/UNSIGNED_FLOAT we already try hard not to fold those immediately
(and still find every now and then spots where we don't do that), for the
rarely used unary rtls we certainly don't.

> In fact Raphael and I were about to submit a patch which takes advantage of
> that capability to improve the code slightly for risc-v.

Just use a pattern with zero_extend or sign_extend around it or subreg of
it?

	Jakub


  reply	other threads:[~2023-01-02 15:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-01 15:55 Roger Sayle
2023-01-01 21:03 ` Segher Boessenkool
2023-01-01 22:59   ` roger
2023-01-02 15:45 ` Jeff Law
2023-01-02 15:59   ` Jakub Jelinek [this message]
2023-01-02 16:20     ` Jeff Law
2023-01-02 17:22       ` Jakub Jelinek
2023-01-02 17:38         ` Jeff Law
2023-01-03 11:33       ` Segher Boessenkool
2023-01-02 17:30   ` roger
2023-01-02 17:47     ` Jeff Law
2023-02-21 15:39 ` Jakub Jelinek
2023-02-26 13:10   ` Roger Sayle
2023-02-27 16:47     ` 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=Y7L/U6+YPVeg1FKC@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=roger@nextmovesoftware.com \
    --cc=segher@kernel.crashing.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).