This is the mail archive of the
mailing list for the GCC project.
Re: Check rrotate optab first when transforming lrotate
- From: "Kewen.Lin" <linkw at linux dot ibm dot com>
- To: Jakub Jelinek <jakub at redhat 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, Segher Boessenkool <segher at kernel dot crashing dot org>, Bill Schmidt <wschmidt at linux dot ibm dot com>
- Date: Mon, 15 Jul 2019 18:39:16 +0800
- Subject: Re: Check rrotate optab first when transforming lrotate
- References: <email@example.com> <20190715085929.GO2125@tucnak>
on 2019/7/15 下午4:59, 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?
> 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.
OK, I see. Thanks for the explanation. I'll try to fix it in the backend.