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
wschm...@linux.vnet.ibm.com
> On Mar 9, 2017, at 6:15 PM, Jakub Jelinek <ja...@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_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
>
