On Wed, 16 Sep 2026, Tamar Christina wrote: > > -----Original Message----- > > From: Richard Sandiford <[email protected]> > > Sent: 16 September 2026 13:08 > > To: Richard Biener <[email protected]> > > Cc: Tamar Christina <[email protected]>; Ezra Sitorus > > <[email protected]>; [email protected]; > > [email protected] > > Subject: Re: [RFC PATCH 3/5] gcc: Add new COMPLEX_DOT_PROD_ROT0 > > IFN/optabs > > > > Richard Biener <[email protected]> writes: > > > On Tue, 15 Sep 2026, Tamar Christina wrote: > > > > > >> > -----Original Message----- > > >> > From: Richard Biener <[email protected]> > > >> > Sent: 15 September 2026 12:50 > > >> > To: Tamar Christina <[email protected]> > > >> > Cc: Ezra Sitorus <[email protected]>; [email protected]; > > >> > [email protected] > > >> > Subject: RE: [RFC PATCH 3/5] gcc: Add new COMPLEX_DOT_PROD_ROT0 > > >> > IFN/optabs > > >> > > > >> > On Tue, 15 Sep 2026, Tamar Christina wrote: > > >> > > > >> > > > -----Original Message----- > > >> > > > From: Richard Biener <[email protected]> > > >> > > > Sent: 15 September 2026 10:16 > > >> > > > To: Tamar Christina <[email protected]> > > >> > > > Cc: Ezra Sitorus <[email protected]>; [email protected]; > > >> > > > [email protected] > > >> > > > Subject: RE: [RFC PATCH 3/5] gcc: Add new > > COMPLEX_DOT_PROD_ROT0 > > >> > > > IFN/optabs > > >> > > > > > >> > > > On Tue, 15 Sep 2026, Tamar Christina wrote: > > >> > > > > > >> > > > > > -----Original Message----- > > >> > > > > > From: Richard Biener <[email protected]> > > >> > > > > > Sent: 15 September 2026 09:23 > > >> > > > > > To: Tamar Christina <[email protected]> > > >> > > > > > Cc: Ezra Sitorus <[email protected]>; gcc- > > [email protected]; > > >> > > > > > [email protected] > > >> > > > > > Subject: RE: [RFC PATCH 3/5] gcc: Add new > > >> > COMPLEX_DOT_PROD_ROT0 > > >> > > > > > IFN/optabs > > >> > > > > > > > >> > > > > > On Tue, 15 Sep 2026, Tamar Christina wrote: > > >> > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > -----Original Message----- > > >> > > > > > > > From: [email protected] <[email protected]> > > >> > > > > > > > Sent: 09 September 2026 19:12 > > >> > > > > > > > To: [email protected] > > >> > > > > > > > Cc: Tamar Christina <[email protected]>; > > >> > [email protected]; > > >> > > > > > > > [email protected]; Ezra Sitorus > > >> > > > <[email protected]> > > >> > > > > > > > Subject: [RFC PATCH 3/5] gcc: Add new > > >> > COMPLEX_DOT_PROD_ROT0 > > >> > > > > > > > IFN/optabs > > >> > > > > > > > > > >> > > > > > > > From: Ezra Sitorus <[email protected]> > > >> > > > > > > > > > >> > > > > > > > Add new internal function COMPLEX_DOT_PROD_ROT0 and > > optab > > >> > > > > > > > cdot_prod_rot0_optab > > >> > > > > > > > to represent complex integer dot product. > > >> > > > > > > > > > >> > > > > > > > COMPLEX_DOT_PROD_ROT0 (A, B, ACC) is a lane-reducing > > signed > > >> > > > integer > > >> > > > > > > > complex > > >> > > > > > > > dot product. The 2 input vectors contain interleaved > > > W-bit real and > > >> > > > > > imaginary > > >> > > > > > > > components in even/odd numbered lanes respectively. Each > > 4W-bit > > >> > > > result > > >> > > > > > > > element > > >> > > > > > > > accumulates the 0-rotation products of the 2 complex > > > input pairs in > > >> > the > > >> > > > > > > > corresponding group of 4 input lanes: > > >> > > > > > > > > > >> > > > > > > > result[j] = acc[j] > > >> > > > > > > > + a[k].re * b[k].re > > >> > > > > > > > - a[k].im * b[k].im > > >> > > > > > > > + a[k + 1].re * b[k + 1].re > > >> > > > > > > > - a[k + 1].im * b[k + 1].im > > >> > > > > > > > > > >> > > > > > > > where 2*j = k. > > >> > > > > > > > > > >> > > > > > > > 0-rotation means that the imaginary components in the > > >> > > > > > > > second > > >> > source > > >> > > > > > vector > > >> > > > > > > > are > > >> > > > > > > > negated, and so the overall operation is accumulating > > > the real part > > >> > of > > >> > > > the > > >> > > > > > > > complex dot product. Other rotations can be added in future > > >> > patches. > > >> > > > > > > > >> > > > > > I other places we use _conj, not rot0: > > >> > > > > > > > >> > > > > > OPTAB_D (cmul_conj_optab, "cmul_conj$a3") > > >> > > > > > > > >> > > > > > so why not use that for consistency? > > >> > > > > > > >> > > > > That's a different operation. complex dotprod is numerically > > >> > > > > > >> > > > Sure, I meant why cdot_prod_rot0 rather than cdot_prod_conj, > > >> > > > complex conjugate is exactly negating the imaginary part? > > >> > > > > >> > > Because the existing cmul/cadd/cdot *_conj optabs are intended to > > >> > > represent the full mathematical complex operation which create both > > >> > > the real and imaginary results. > > >> > > > > >> > > Yes, cdot #0 conjugates the second operand in the sense that it uses > > >> > > ar * br - ai * bi. But it only computes the real component of the > > >> > > complex dot product. The imaginary component is not computed. > > >> > > > >> > Oh, but then the name cdot_* is even more confusing? Why even bother > > >> > with naming it "complex" then? It's not even a dot product? > > >> > > >> Agreed! Hence my ask for Ezra to document the operations so we could see > > >> what they all mean. > > >> > > >> > > > >> > res += a[i].real * b[i].real > > >> > - a[i].imag * b[i].imag; > > >> > > > >> > that suggests cdot0 computes > > >> > > > >> > res + x * y - z * w > > >> > > > >> > or is it, for vectors, even more complicates as > > >> > > > >> > res + x[2*n] * y[2*n] - x[2*n+1] * y[2*n+1] > > >> > > > >> > ? Aka it's an alternating plus/minus non-"complex" dot-product > > >> > > > >> > (res + x[2*n] * y[2*n]) - x[2*n+1] * y[2*n+1] > > >> > > >> Yeah. > > >> > > >> > > > >> > as if negating every other lane in x[] and then using a regular > > >> > (non-complex) dot product? And it's also a reduction, so > > >> > reduc_dot_<?>_scal? with <?> standing for whatever we invent > > >> > for the alternating negation (we have vec_addsub and vec_fmaddsub > > >> > and vec_fmsubadd for example, but that's not reductions). > > >> > > > >> > > >> Yeah, reduc_dot_addsub_scal sounds quite funky hehe. Is the "dot" in > > >> that case relevant? Why not just reduc_dot_addsub_scal? But that said > > >> my issue is still I'm not sure this scales to the other operations. > > >> > > >> Like rot90 is > > >> > > >> res + x[2*n] * y[2*n+1] + x[2*n+1] * y[2*n] > > >> > > >> so do we do reduc_dot_addadd_scal or reduc_addadd_scal? That's why > > >> we just kept the rot0 in the name before on BZ. > > > > > > So there's still the question - is the "accumulator" really a scalar > > > or is it a vector? From reading the SVE2 'CDOT' docs it appears > > > that it's a vector but with half of the lanes as the input > > > vectors? > > > > Not sure whether you were reading the ISA docs or the intrinsic docs, > > but FWIW, I tried to describe the operation more clearly in the > > intrinsics docs: > > > > https://developer.arm.com/architectures/instruction- > > sets/intrinsics/#q=cdot > > > > > So _scal would be inappropriate. Instead it would be a > > > lane-reducing (but not widening? CDOT is an integer vector operation?) > > > operation? In which case reduc_dot_addsub. Or if we want to > > > stick with 'cdot' and 'rot' maybe cdot_rot0_real and while > > > the docs say rot90 is _imag it's rotated to real position, so > > > cdot_rot90_real as well (only _real would remain). Or > > > cdot_real and cdot_imag. But then the other rotates would have > > > to be _conj in addition to _real and _imag? > > > > IMO we have two binary choices: > > > > - is the second operand conjugated? > > - are the real or imaginary elements of the result accumulated? > > > > Perhaps we should express it in those terms, rather than as a rotation? > > > > I agree that _scal is inappropriate. > > I was going to get back to this today but haven't had time yet to respond. > > As I mentioned in my other email, the instructions *are* widening and > lane reducing but are not scalar reductions. Every 8 elements in the input > lanes (4 in each vector) are reduced to 1 in the output lane. So e.g. 8 bytes > reduce to an int. > and the results are always the real or the imaginary component. > > https://dougallj.github.io/asil/doc/cdot_z_zzz_0_8.html Shows a pretty good > diagram. > > This means that unlike normal complex numbers operations you need a permute > if you want > to reconstruct the original complex result. > > For that reason I would still not name them the same as the current optabs > and IFN and require > The suffix. So cdot_real, cdot_imag, cdot_conj_real and cdot_conj_imag. No > "reduc_" prefix since we also don't call the normal dotprod a reduc_dotprod.
I want to point to https://gcc.gnu.org/pipermail/gcc-patches/2026-August/727035.html and the previous discussion. Yes, that only renamed widen_[us]sum, not other lane-reducing optabs. Richard. > Thanks, > Tamar > > > > > Thanks, > > Richard > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri; (HRB 36809, AG Nuernberg)
