On Mon, Jul 15, 2019 at 10:59 AM Jakub Jelinek <ja...@redhat.com> 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 > define_expand. > > 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.
Agreed. Or alternatively improve the generic expander. Richard. > Jakub
