This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, rs6000] (3/3) Fix mulv4si3 and mulv8hi3 patterns for little endian
- From: Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>
- To: Richard Sandiford <rsandifo at linux dot vnet dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, dje dot gcc at gmail dot com
- Date: Mon, 04 Nov 2013 10:29:33 -0600
- Subject: Re: [PATCH, rs6000] (3/3) Fix mulv4si3 and mulv8hi3 patterns for little endian
- Authentication-results: sourceware.org; auth=none
- References: <1383543684 dot 6275 dot 312 dot camel at gnopaine> <874n7sjhh5 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
On Mon, 2013-11-04 at 15:48 +0000, Richard Sandiford wrote:
> Bill Schmidt <wschmidt@linux.vnet.ibm.com> writes:
> > + /* We need this to be vmulouh for both big and little endian,
> > + but for little endian we would swap this, so avoid that. */
> > + if (BYTES_BIG_ENDIAN)
> > + emit_insn (gen_vec_widen_umult_odd_v8hi (low_product, one, two));
> > + else
> > + emit_insn (gen_vec_widen_umult_even_v8hi (low_product, one, two));
>
> FWIW, an alternative would be to turn vec_widen_smult_{even,odd}_* into
> define_expands and have define_insns for the underlying instructions.
> E.g. vec_widen_umult_even_v16qi could call gen_vmuleub or gen_vmuloub
> depending on endianness.
>
> Then the unspec name would always match the instruction, and you could
> also use gen_vmulouh rather than gen_vec_widen_umult_*_v8hi above.
>
> It probably works out as more code overall, but maybe it means jumping
> through fewer mental hoops...
Good idea. I'll have a look and produce a new patch set shortly.
Thanks,
Bill
>
> Thanks,
> Richard