On 7/9/2022 下午 10:25, Segher Boessenkool wrote: > Hi! > > On Wed, Sep 07, 2022 at 08:51:17AM -0500, Paul A. Clarke wrote: >> On Tue, Sep 06, 2022 at 12:19:06PM -0500, Segher Boessenkool wrote: >>> On Mon, Sep 05, 2022 at 02:36:30PM +0800, HAO CHEN GUI wrote: >>>> The return type of vec_ version built-ins are different than their >>>> definition >>>> in PVIPR. In PVIPR, they're vector unsigned int or vector unsigned long >>>> long. >>>> Shall we correct them? >>>> >>>> const vd __builtin_vsx_extract_exp_dp (vd); >>>> VEEDP xvxexpdp {} >>>> >>>> const vf __builtin_vsx_extract_exp_sp (vf); >>>> VEESP xvxexpsp {} >>>> >>>> const vd __builtin_vsx_extract_sig_dp (vd); >>>> VESDP xvxsigdp {} >>>> >>>> const vf __builtin_vsx_extract_sig_sp (vf); >>>> VESSP xvxsigsp {} >>> >>> Those are the vsx_ versions. I'm not sure what you're asking. >>> >>> It won't be easy at all to change types from vector integer to vector >>> float, it will break all over. A compatibility nightmare. It is better >>> if you can show the current stuff cannot ever work, it's not a problem >>> to replace it in that case. >> >> I think Hao Chen is concerned about the return types: > > Yes, and so am I. > >>>> const vd __builtin_vsx_extract_exp_dp (vd); >>>> VEEDP xvxexpdp {} >> >> Per PVIPR, this should return vector unsigned long long ("vull" not "vd"). > > But changing that will make any existing code that now works, fail > horribly. Of course it is possible no such code exists :-) > > What did this do before the builtin rewrite? > > > ~ - ~ - ~ > > > It looks like it did the right thing before, but that is just based on > reading the code, I haven't actually tried it :-) > > So, changing the vsx_ code here should be okay, because obviously no one > is using it. OTOH, why do we have those separately at all, why do they > not just redirect to the canonical vec_ versions? Or, can we just get > rid of the vsx_ version completely? In rs6000-overload.def, the vsx_ version built-ins are overridden to vec_ version. And the return types of vec_ version is inline with those defined in PVIPR. So there should be no problem. Sorry for that. [VEC_VEEDP, vec_extract_exp_dp, __builtin_vec_extract_exp_dp] vull __builtin_vec_extract_exp_dp (vd); VEEDP VEEDP_DEPR1 [VEC_VEESP, vec_extract_exp_sp, __builtin_vec_extract_exp_sp] vui __builtin_vec_extract_exp_sp (vf); VEESP VEESP_DEPR1 [VEC_VEE, vec_extract_exp, __builtin_vec_extract_exp] vui __builtin_vec_extract_exp (vf); VEESP vull __builtin_vec_extract_exp (vd); VEEDP Thanks Gui Haochen
RE: [PATCH v2, rs6000] Change insn condition from TARGET_64BIT to TARGET_POWERPC64 for VSX scalar extract/insert instructions
HAO CHEN GUI via Gcc-patches Wed, 07 Sep 2022 22:59:20 -0700
- [PATCH v2, rs6000] Change insn condition fr... HAO CHEN GUI via Gcc-patches
- Re: [PATCH v2, rs6000] Change insn con... Segher Boessenkool
- Re: [PATCH v2, rs6000] Change insn... HAO CHEN GUI via Gcc-patches
- Re: [PATCH v2, rs6000] Change ... Segher Boessenkool
- Re: [PATCH v2, rs6000] Cha... Paul A. Clarke via Gcc-patches
- Re: [PATCH v2, rs6000... Segher Boessenkool
- RE: [PATCH v2, rs... HAO CHEN GUI via Gcc-patches
- Re: [PATCH v2... Segher Boessenkool
- RE: [PATCH v2... HAO CHEN GUI via Gcc-patches
- Re: [PATCH v2, rs6000] Cha... HAO CHEN GUI via Gcc-patches
- Re: [PATCH v2, rs6000... Iain Sandoe via Gcc-patches