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.