volk_32fc_s32f_atan2_32f: Add NaN tests for avx2 and avx2_fma code

[jj1bdx]

This adds a NaN test after the division operation of volk_32fc_s32f_atan2_32f avx2 and avx2_fma code.

This patch solves the issue in #730.

Using volk_profile, the processing time will increase by 17% on my environment of Intel NUC NUC10i7FNH with Intel(R) Core(TM) i7-10710U CPU. I believe this is a necessary cost to maintain full compatibility with the past (i.e., VOLK v3.0.0 and previous) implementations.

[jj1bdx]

volk_profile benchmark results:

With old v3.1.0 code:

RUN_VOLK_TESTS: volk_32fc_s32f_atan2_32f(131071,1987)
generic completed in 7078.28 ms
polynomial completed in 2318.11 ms
a_avx2_fma completed in 175.141 ms
a_avx2 completed in 175.124 ms
u_avx2_fma completed in 174.965 ms
u_avx2 completed in 176.404 ms
Best aligned arch: u_avx2_fma
Best unaligned arch: u_avx2_fma

With the code proposed in this pull request:

RUN_VOLK_TESTS: volk_32fc_s32f_atan2_32f(131071,1987)
generic completed in 7075.16 ms
polynomial completed in 2343.78 ms
a_avx2_fma completed in 204.169 ms
a_avx2 completed in 204.303 ms
u_avx2_fma completed in 204.389 ms
u_avx2 completed in 204.4 ms
Best aligned arch: a_avx2_fma
Best unaligned arch: u_avx2_fma

Processing time increase rate: 204/175 ~= 1.166

[jdemel]

According to Wikipedia atan2, one would expect a NaN for 0.0+0.0j. Changing this behavior in VOLK would potentially cause trouble.

Before the new AVX2 and AVX2 FMA kernels, we would basically always use the atan2 function from the standard.

atan2f(0.0, 0.0) == 0.0;

Thus, this fix makes sense to align the ouputs.

[argilo]

Normally VOLK strives for maximum performance, but I agree that we should avoid returning NaN, because that can be catastrophic in DSP contexts. (For instance, if an IIR filter receives a single NaN sample, then all future outputs become NaN.)

[marcusmueller]

I must admit I especially don't like the fallback on the generic implementation at the end of loops here. This kernel is used for phase estimations, and minor implementation details (like whether to jump to -pi or +pi for zero x, positive or negative y) makes it hard to debug this and to use it. Could we maybe just for the "leftover" iteration fill a set MM register with the inputs that are available, run the regular SIMD on it, then instead of storing the whole result, just cherry-pick these elements that are actually based on input?

[marcusmueller]

might be worth checking what sleef does here.

[jdemel]

LGTM. This PR fixes situation where a NaN may corrupt a system. We should really avoid that.

The other concerns, e.g. how to handle the tail case, are valid but out of scope.

[jj1bdx]

@jdemel Thanks for merging!