This is the mail archive of the
mailing list for the GCC project.
Re: Check rrotate optab first when transforming lrotate
- From: Jakub Jelinek <jakub at redhat dot com>
- To: "Kewen.Lin" <linkw at linux dot ibm dot com>
- Cc: 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 10:59:29 +0200
- Subject: Re: Check rrotate optab first when transforming lrotate
- References: <firstname.lastname@example.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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?
Especially for rotates by constant, you can transform those in the
Canonicalizing code is highly desirable during GIMPLE, it means if you have
say left rotate by 23 in one spot and right rotate by bitsize - 23 in
another spot, e.g. SCCVN can merge that code.
So, IMNSHO, just improve the backend.