On Wed, Jul 17, 2019 at 12:54:32PM +0200, Jakub Jelinek wrote: > On Wed, Jul 17, 2019 at 12:37:59PM +0200, Richard Biener wrote: > > I'm not sure if it makes sense to have both LROTATE_EXPR and > > RROTATE_EXPR on the GIMPLE level then (that CPUs only > > support one direction is natural though). So maybe simply get > > rid of one? Its semantics are also nowhere documented > > A lot of targets support both,
Of all the linux targets, we have: No rotate: alpha microblaze riscv sparc Both directions: aarch64 c6x ia64 m68k nios2 parisc sh x86 xtensa Left only: csky h8300 powerpc s390 Right only: arc arm mips nds32 openrisc > Then there are some targets that only support left rotates and not right > rotates (rs6000, s390, tilegx, ...), and other targets that only support > right rotates (mips, iq2000, ...). > So only having one GIMPLE code doesn't seem to be good enough. > > I think handling it during expansion in generic code is fine, especially > when we clearly have several targets that do support only one of the > rotates. As you wrote, it needs corresponding code in tree-vect-generic.c, > and shouldn't hardcode the rs6000 direction of mapping rotr to rotl, but > support also the other direction - rotl to rotr. For the sake of > !SHIFT_COUNT_TRUNCATED targets for constant shift counts it needs to do > negation + masking and for variable shift counts probably punt and let the > backend code handle it if it can do the truncation in there? I think we can say that *all* targets behave like SHIFT_COUNT_TRUNCATED for rotates? Not all immediates are valid of course, but that is a separate issue. Segher
