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?
Segher
