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 > 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. Thanks, Richard
