This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] [PATCH, rs6000] Fix pr79941 (v2)
Just so there's no duplication of effort -- I'll follow up with a patch to remove the
outdated built-in.
-- 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 10, 2017, at 8:24 AM, Bill Schmidt <wschmidt@linux.vnet.ibm.com> wrote:
>
> 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
>>
>