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 wschm...@linux.vnet.ibm.com > On Mar 10, 2017, at 8:24 AM, Bill Schmidt <wschm...@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 > 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 >> >