[PATCH, rs6000] Use hardware support for vector character multiply

Bill Schmidt wschmidt@linux.vnet.ibm.com
Thu Sep 3 15:53:00 GMT 2015


On Thu, 2015-09-03 at 11:36 -0400, David Edelsohn wrote:
> On Thu, Sep 3, 2015 at 11:20 AM, Bill Schmidt
> <wschmidt@linux.vnet.ibm.com> wrote:
> > Hi,
> >
> > It was pointed out to me recently that multiplying two vector chars is
> > performed using scalarization, even though we have hardware support for
> > byte multiplies in vectors.  This patch adds an expansion for mulv16qi3
> > to correct this.
> >
> > The expansion is pretty simple.  We do a multiply-even and multiply-odd
> > to create halfword results, and then use a permute to extract the
> > low-order bytes of each result.  This particular form of a permute uses
> > a different set of input/output vector modes than have been used before,
> > so I added the altivec_vperm_v8hiv16qi insn to represent this.  (The two
> > source operands are vector halfword types, while the target operand is a
> > vector char type.)
> >
> > I've added two test variants, one to test the code generation, and one
> > executable test to check correctness.  One other test failed with this
> > change.  This turned out to be because PowerPC was excluded from the
> > check_effective_target_vect_char_mult target support test.  I resolved
> > this by adding check_effective_target_powerpc_altivec to that test.
> >
> > Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> > regressions.  Is this ok for trunk?
> >
> > Thanks,
> > Bill
> >
> >
> > [gcc]
> >
> > 2015-09-03  Bill Schmidt  <wschmidt@vnet.linux.ibm.com>
> >
> >         * config/rs6000/altivec.md (altivec_vperm_v8hiv16qi): New
> >         define_insn.
> >         (mulv16qi3): New define_expand.
> >
> > [gcc/testsuite]
> >
> > 2015-09-03  Bill Schmidt  <wschmidt@vnet.linux.ibm.com>
> >
> >         * gcc.target/powerpc/vec-mult-char-1.c: New test.
> >         * gcc.target/powerpc/vec-mult-char-2.c: New test.
> 
> This is okay.
> 
> The "bool be = BYTES_BIG_ENDIAN" and use of "be" is not a common style in GCC.

OK.  I thought that helped with readability, but I will revise this to
use BYTES_BIG_ENDIAN directly in the expressions.

Thanks,
Bill

> 
> Thanks, David
> 




More information about the Gcc-patches mailing list