From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/2] powerpc/bitops: Use immediate operand when possible
Date: Tue, 13 Apr 2021 18:33:19 +0200 [thread overview]
Message-ID: <ecb1b1a5-ae92-e8a3-6490-26341edfbccb@csgroup.eu> (raw)
In-Reply-To: <20210412215428.GM26583@gate.crashing.org>
Le 12/04/2021 à 23:54, Segher Boessenkool a écrit :
> Hi!
>
> On Thu, Apr 08, 2021 at 03:33:44PM +0000, Christophe Leroy wrote:
>> For clear bits, on 32 bits 'rlwinm' can be used instead or 'andc' for
>> when all bits to be cleared are consecutive.
>
> Also on 64-bits, as long as both the top and bottom bits are in the low
> 32-bit half (for 32 bit mode, it can wrap as well).
Yes. But here we are talking about clearing a few bits, all other ones must remain unchanged. An
rlwinm on PPC64 will always clear the upper part, which is unlikely what we want.
>
>> For the time being only
>> handle the single bit case, which we detect by checking whether the
>> mask is a power of two.
>
> You could look at rs6000_is_valid_mask in GCC:
> <https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/rs6000/rs6000.c;h=48b8efd732b251c059628096314848305deb0c0b;hb=HEAD#l11148>
> used by rs6000_is_valid_and_mask immediately after it. You probably
> want to allow only rlwinm in your case, and please note this checks if
> something is a valid mask, not the inverse of a valid mask (as you
> want here).
This check looks more complex than what I need. It is used for both rlw... and rld..., and it
calculates the operants. The only thing I need is to validate the mask.
I found a way: By anding the mask with the complement of itself rotated by left bits to 1, we
identify the transitions from 0 to 1. If the result is a power of 2, it means there's only one
transition so the mask is as expected.
So I did that in v2.
>
> So yes this is pretty involved :-)
>
> Your patch looks good btw. But please use "n", not "i", as constraint?
Done.
Christophe
next prev parent reply other threads:[~2021-04-13 16:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-08 15:33 [PATCH v1 1/2] powerpc/bitops: Use immediate operand when possible Christophe Leroy
2021-04-08 15:33 ` [PATCH v1 2/2] powerpc/atomics: " Christophe Leroy
2021-04-12 22:08 ` Segher Boessenkool
2021-04-13 16:36 ` Christophe Leroy
2021-04-12 21:54 ` [PATCH v1 1/2] powerpc/bitops: " Segher Boessenkool
2021-04-13 16:33 ` Christophe Leroy [this message]
2021-04-13 21:58 ` Segher Boessenkool
2021-04-14 2:01 ` Nicholas Piggin
2021-04-14 12:24 ` Segher Boessenkool
2021-04-14 12:42 ` Christophe Leroy
2021-04-14 15:19 ` Segher Boessenkool
2021-04-14 15:32 ` David Laight
2021-04-14 17:20 ` 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=ecb1b1a5-ae92-e8a3-6490-26341edfbccb@csgroup.eu \
--to=christophe.leroy@csgroup.eu \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--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 NNTP newsgroup(s).