From: "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>
To: Segher Boessenkool <segher@kernel.crashing.org>,
Jakub Jelinek <jakub@redhat.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
"Kewen.Lin" <linkw@linux.ibm.com>,
GCC Patches <gcc-patches@gcc.gnu.org>,
Richard Sandiford <richard.sandiford@arm.com>,
Bill Schmidt <wschmidt@linux.ibm.com>
Subject: Re: [RFC] Consider lrotate const rotation in vectorizer
Date: Thu, 18 Jul 2019 15:17:00 -0000 [thread overview]
Message-ID: <be588062-aaf0-dc41-abe5-61a076bf527a@arm.com> (raw)
In-Reply-To: <20190717170032.GO20882@gate.crashing.org>
On 17/07/2019 18:00, Segher Boessenkool wrote:
> On Wed, Jul 17, 2019 at 12:54:32PM +0200, Jakub Jelinek wrote:
>> On Wed, Jul 17, 2019 at 12:37:59PM +0200, Richard Biener wrote:
>>> I'm not sure if it makes sense to have both LROTATE_EXPR and
>>> RROTATE_EXPR on the GIMPLE level then (that CPUs only
>>> support one direction is natural though). So maybe simply get
>>> rid of one? Its semantics are also nowhere documented
>>
>> A lot of targets support both,
>
> Of all the linux targets, we have:
>
> No rotate:
> alpha microblaze riscv sparc
>
> Both directions:
> aarch64 c6x ia64 m68k nios2 parisc sh x86 xtensa
AArch64 is Right only.
R.
>
> Left only:
> csky h8300 powerpc s390
>
> Right only:
> arc arm mips nds32 openrisc
>
>> Then there are some targets that only support left rotates and not right
>> rotates (rs6000, s390, tilegx, ...), and other targets that only support
>> right rotates (mips, iq2000, ...).
>> So only having one GIMPLE code doesn't seem to be good enough.
>>
>> I think handling it during expansion in generic code is fine, especially
>> when we clearly have several targets that do support only one of the
>> rotates. As you wrote, it needs corresponding code in tree-vect-generic.c,
>> and shouldn't hardcode the rs6000 direction of mapping rotr to rotl, but
>> support also the other direction - rotl to rotr. For the sake of
>> !SHIFT_COUNT_TRUNCATED targets for constant shift counts it needs to do
>> negation + masking and for variable shift counts probably punt and let the
>> backend code handle it if it can do the truncation in there?
>
> I think we can say that *all* targets behave like SHIFT_COUNT_TRUNCATED
> for rotates? Not all immediates are valid of course, but that is a
> separate issue.
>
>
> Segher
>
next prev parent reply other threads:[~2019-07-18 15:12 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-15 8:59 Check rrotate optab first when transforming lrotate Kewen.Lin
2019-07-15 9:16 ` Jakub Jelinek
2019-07-15 9:19 ` Richard Biener
2019-07-15 9:20 ` Richard Sandiford
2019-07-15 10:54 ` Kewen.Lin
2019-07-15 14:51 ` Segher Boessenkool
[not found] ` <d2ccc831-c805-c7b8-5a90-cb3e5ee5ed8b@linux.ibm.com>
2019-07-16 8:48 ` [RFC] Consider lrotate const rotation in vectorizer Kewen.Lin
2019-07-17 8:42 ` [PATCH, rs6000] Support vrotr<mode>3 for int vector types Kewen.Lin
2019-07-17 8:44 ` Jakub Jelinek
2019-07-17 9:38 ` Kewen.Lin
2019-07-17 10:18 ` Jakub Jelinek
2019-07-17 13:48 ` Segher Boessenkool
2019-07-18 6:06 ` Kewen.Lin
2019-07-18 20:06 ` Segher Boessenkool
2019-07-19 6:51 ` Kewen.Lin
2019-07-19 15:49 ` Segher Boessenkool
2019-07-23 7:32 ` [PATCH V2, " Kewen.Lin
2019-07-25 14:24 ` Segher Boessenkool
2019-07-26 3:33 ` [PATCH V3, " Kewen.Lin
2019-07-26 3:37 ` [PATCH V4, " Kewen.Lin
2019-07-26 14:28 ` [PATCH V3, " Segher Boessenkool
2019-08-02 8:59 ` [PATCH V5, " Kewen.Lin
2019-08-03 20:52 ` Segher Boessenkool
2019-08-05 3:41 ` Kewen.Lin
2019-08-05 21:50 ` Segher Boessenkool
2019-08-06 3:11 ` Kewen.Lin
2019-08-06 15:12 ` Segher Boessenkool
2019-07-17 10:39 ` [RFC] Consider lrotate const rotation in vectorizer Richard Biener
2019-07-17 11:19 ` Jakub Jelinek
2019-07-17 11:35 ` Richard Biener
2019-07-17 11:56 ` Richard Biener
2019-07-17 13:58 ` Segher Boessenkool
2019-07-17 17:51 ` Segher Boessenkool
2019-07-18 7:03 ` Jakub Jelinek
2019-07-18 19:45 ` Segher Boessenkool
2019-07-18 15:17 ` Richard Earnshaw (lists) [this message]
2019-07-18 15:26 ` Jakub Jelinek
2019-07-18 15:31 ` Richard Earnshaw (lists)
2019-07-18 15:35 ` Jakub Jelinek
2019-07-18 15:44 ` Richard Earnshaw (lists)
2019-07-18 18:04 ` Segher Boessenkool
2019-07-18 6:28 ` Kewen.Lin
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=be588062-aaf0-dc41-abe5-61a076bf527a@arm.com \
--to=richard.earnshaw@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=linkw@linux.ibm.com \
--cc=richard.guenther@gmail.com \
--cc=richard.sandiford@arm.com \
--cc=segher@kernel.crashing.org \
--cc=wschmidt@linux.ibm.com \
/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).