On Tue, 22 Jun 2021, Uros Bizjak wrote:

> On Tue, Jun 22, 2021 at 11:42 AM Richard Sandiford
> <richard.sandif...@arm.com> wrote:
> 
> > >> Well, the pattern is called addsub in the x86 world because highpart
> > >> does add and lowpart does sub. In left-to-right writing systems
> > >> highpart comes before lowpart, so you have addsub.
> > >
> > > The other targets mentioned do not seem to agree but I can live
> > > with that, thus I'll change back to addsub.
> >
> > FWIW, subadd sounds clearer to me too.  It seems surprising to put
> > imaginary before real when interpreting something as complex, for example.
> >
> > Putting the highpart first feels especially odd on an LE system like x86…
> 
> The XMM vector is documented left to right with MSB at the left (c.f.
> most significant *DIGIT* of the number at the left)
> 
> xmm[MSB] .... xmm[LSB]
> 
> so, looking at x86 ADDSUBPD insn documentation:
> 
> xmm2[127:64] xmm2[63:0]
> ( + -)
> xmm1[127:64] xmm1[63:0]
> (=)
> xmm1[127:64] holds ADD
> xmm1[63:0] holds SUB
> 
> xmm1[127:64] xmm1 [63:0]
> ADD SUB

I think if we really want to resolve the "ambiguity" we have to
spell it out in the optab.  vec_addodd_subeven or vec_addsub_oddeven.
As I noted there are targets who have the opposite so we could
then add vec_addsub_evenodd (not vec_subadd_evenodd).

Just tell me what you prefer - I'll adjust the patch accordingly.

Richard.

Reply via email to