On Wed, 16 Sep 2026, Richard Sandiford wrote: > 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]>; [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
Ah, much better. So yes, I ended up reading the ISA docs (first google hit). I'll try to remember looking for intrinsic docs in the future. > > 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? Yes, I think that's better and more consistent. So it would be reduc_cdot_conj. There's also the rot90 vs. rot180 case of swapping op3 real/imag parts, and we have cadd90 and cadd270 where that is either conj and then swap or swap and then conj of the 2nd operand. > I agree that _scal is inappropriate. > > 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)
