This is the mail archive of the
mailing list for the GCC project.
Re: Check rrotate optab first when transforming lrotate
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: "Kewen.Lin" <linkw at linux dot ibm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Biener <richard dot guenther at gmail dot com>, richard dot sandiford at arm dot com
- Date: Mon, 15 Jul 2019 09:44:07 -0500
- Subject: Re: Check rrotate optab first when transforming lrotate
- References: <email@example.com> <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
Canonicalising this representation is highly desirable. Everything in
RTL already does work fine, fwiw (and did since before rotatert