On 17/07/2019 18:00, Segher Boessenkool wrote:
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
AArch64 is Right only.
R.
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
