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

[Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>]

Jumping in so we can continue the Will/Bill confusion: ;)

The official prototypes from the original AltiVec PIM are:

vector unsigned short vec_mule (vector unsigned char, vector unsigned char);
vector signed short vec_mule (vector signed char, vector signed char);

vector unsigned int vec_mule (vector unsigned short, vector unsigned short);
vector signed int vec_mule (vector signed short, vector signed short);

These are still the only supported forms.  For POWER9, we are adding similar
prototypes for 32-bit multiplies with a 64-bit result.

I do not know why we have this _UNS variant, but it seems to be something
we can do without.  It does not appear in the built-in table in rs6000-c.c  All
the entries in that built-in table are type-correct with respect to the above
definitions.  We should delete that entry from rs6000-builtin.def.

-- Bill

Bill Schmidt, Ph.D.
GCC for Linux on Power
Linux on Power Toolchain
IBM Linux Technology Center
wschmidt@linux.vnet.ibm.com

> On Mar 9, 2017, at 6:15 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> 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
>