On Thu, Mar 09, 2017 at 07:01:06PM -0500, Michael Meissner wrote:
> > > This looks good to me, but I'll defer the actual review to PowerPC
> > > maintainers. Perhaps there was some hidden reason (xlC compatibility,
> > > whatever) that said that vmuleub etc. should have signed vector arguments
> > > and result.
> > >
> > > Also, I'd like to understand what those ALTIVEC_BUILTIN_VMULEUH_UNS etc.
> > > codes are for (the builtin doesn't seem to be user accessible).
> >
> > It used to be, but that was removed when mult-even was removed (which
> > seems to be the only thing it was used for). Mike, do you remember?
>
> I don't recall. Perhaps it is related to:
>
> 2016-12-19 Will Schmidt <will_schm...@vnet.ibm.com>
>
> * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Add handling for
> early expansion of vector multiply and subtract builtins.
That added the folding. The questions are:
1) if it is intentional that ALTIVEC_BUILTIN_VMULEUH etc. used signed rather
than unsigned vector types as arguments and return value (and if yes, why)?
BU_ALTIVEC_2 (VMULEUH, "vmuleuh", CONST,
vec_widen_umult_even_v8hi)
BU_ALTIVEC_2 (VMULEUH_UNS, "vmuleuh_uns", CONST,
vec_widen_umult_even_v8hi)
and builtin_function_type only mentioning
/* unsigned 2 argument functions. */
case ALTIVEC_BUILTIN_VMULEUH_UNS:
Back e.g. in 4.6 UNS was used in targetm.vectorize.builtin_mul_widen_even.
Does the Altivec spec say that that vec_vmuleuh arguments should be
vector signed short? For vec_mule it chooses {uh,ub,sh,sb} depending on
whether the arguments are signed/unsigned and short/char vectors.
2) can we now remove ALTIVEC_BUILTIN_VMULEUH_UNS etc.?
Jakub
