This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Consider lrotate const rotation in vectorizer
- From: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>, Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, "Kewen.Lin" <linkw at linux dot ibm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Sandiford <richard dot sandiford at arm dot com>, Bill Schmidt <wschmidt at linux dot ibm dot com>
- Date: Thu, 18 Jul 2019 16:12:48 +0100
- Subject: Re: [RFC] Consider lrotate const rotation in vectorizer
- References: <email@example.com> <20190715085929.GO2125@tucnak> <firstname.lastname@example.org> <email@example.com> <CAFiYyc1rVc=GsJTN1w9B5DAGATjrcb7vYp8UH1Sqjbm-G2vZzQ@mail.gmail.com> <20190717105432.GG2125@tucnak> <20190717170032.GO20882@gate.crashing.org>
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:
alpha microblaze riscv sparc
aarch64 c6x ia64 m68k nios2 parisc sh x86 xtensa
AArch64 is Right only.
csky h8300 powerpc s390
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