[PATCH] [PATCH, rs6000] Fix pr79941 (v2)

[Jakub Jelinek]

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_schmidt@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