[PATCH][RFC] Add x86 subadd SLP pattern

Uros Bizjak ubizjak@gmail.com
Tue Jun 22 10:49:06 GMT 2021


On Tue, Jun 22, 2021 at 12:34 PM Richard Biener <rguenther@suse.de> wrote:
>
> On Tue, 22 Jun 2021, Uros Bizjak wrote:
>
> > On Tue, Jun 22, 2021 at 11:42 AM Richard Sandiford
> > <richard.sandiford@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.

I'd use addsub when add comes at the left of sub, and MSB is also
considered at the left. subadd for when sub comes at the left of add
where MSB is also at the left.

I think that the documentation should clear the ambiguity.

Otherwise, just my 0.02€, I don't want to bikeshed about this ad
infinitum, so I'll stop there.

Uros.


More information about the Gcc-patches mailing list