public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Jakub Jelinek <jakub@redhat.com>
Cc: "Kewen.Lin" <linkw@linux.ibm.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	       Richard Biener <richard.guenther@gmail.com>,
	richard.sandiford@arm.com
Subject: Re: Check rrotate optab first when transforming lrotate
Date: Mon, 15 Jul 2019 14:51:00 -0000	[thread overview]
Message-ID: <20190715144407.GE20882@gate.crashing.org> (raw)
In-Reply-To: <20190715085929.GO2125@tucnak>

On Mon, Jul 15, 2019 at 10:59:29AM +0200, Jakub Jelinek wrote:
> On Mon, Jul 15, 2019 at 04:50:13PM +0800, Kewen.Lin wrote:
> > In match.pd and expmed.c, we have some codes to transform lrotate to 
> > rrotate if rotation count is const.  But they don't consider the target
> > whether supports the rrotate.  It leads to some suboptimal generated
> > code since some optimization can't get expected result by querying
> > target optab.  One typical case is that we miss some rotation 
> > vectorization opportunity on Power.
> 
> This will not do the right thing if neither lrotate nor rrotate is
> supported, you want to canonicalize in that case IMHO.
> The code formatting is wrong (|| at the end of line, overly long lines).
> 
> Finally, what is the reason why Power doesn't support one of the rotates?

Because it is pointless duplication, and we have some dozen rotate
patterns already.

Canonicalising this representation is highly desirable.  Everything in
RTL already does work fine, fwiw (and did since before rotatert
existed).


Segher

  parent reply	other threads:[~2019-07-15 14:44 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-15  8:59 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 [this message]
     [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)
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=20190715144407.GE20882@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --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 \
    /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).