Re: [VOLK] a += b*c ?

[Marcus Müller]

Do we have documentation that an `add` implementation must be able to 
work in-place? Otherwise, we should probably write that down :)

Also, on the API: C99 wise, I'm pretty sure this is a strict aliasing 
rule violation: pointers of different types mustn't point to the same 
data. The compiler is totally allowed to assume the first and second 
argument to volk_32f_x2_add_32f are pointing *distinct* objects, and 
hence could optimize as if the (const) a never changes as soon as the 
function has been entered. But exactly that happens. Don't see how this 
can go wrong for an operation like addition, but I honestly think the 
semantics of type_x2_operation_type should be that two inputs that are 
not the output are passed. If we want in-place kernels, we should 
probably have them separately.

Cheers,
Marcus


On 8/16/22 14:13, Johannes Demel wrote:
> Hi Randall,
>
> in your case,
>
> https://github.com/gnuradio/volk/blob/main/kernels/volk/volk_32f_x2_multiply_32f.h 
>
>
> followed by
> https://github.com/gnuradio/volk/blob/main/kernels/volk/volk_32f_x2_add_32f.h 
>
>
> would be the way to go at the moment.
> ```
> volk_32f_x2_multiply_32f(multiply_result, b, c, num_samples);
> volk_32f_x2_add_32f(a, a, multiply_result, num_samples);
> ```
>
> You're welcome to start a new kernel
> ```
> volk_32f_x3_multiply_add_32f(out, a, b, c, num_samples);
> ```
> In fact, it would be a great addition to VOLK.
>
> Cheers
> Johannes
>
>
> On 16.08.22 01:38, Randall Wayth wrote:
> > Thanks for the suggestions and apologies for not being 100% clear at 
> > the start.
> > I'm not looking for a dot product. I'm looking for
> > a[i] += b[i]*c[i]     specifically for floating point
> >
> > So it would be the equivalent of IPP's ippsAddProduct_32f.
> > The application is to apply a window to a set of samples before 
> > accumulating, to implement a weighted overlap add PFB. In my case the 
> > samples are real-valued, but I could also see a case for a and b 
> > being complex, or the case for b being 8 or 16-bit ints with a and c 
> > being floating point.
> >
> > Cheers,
> > Randall