remove buggy and slow neonv8 kernel

[marcusmueller]

as noticed by argilo when fixing the integer generation in #677 , that kernel was buggy. It seems compilers are better at building byte-swapping code than people writing SIMD intrinsics, so falling back on generic doesn't hurt.

[argilo]

Looks like this kernel has been slower than generic since it was added in #196. Good riddance.

[argilo]

For the record, the bug in the implementation was that the load (vld2q_u8) & store (vst2q_u8) were interleaved:

VLD2 loads 2 vectors from memory. It performs a 2-way de-interleave from memory to the vectors.

[marcusmueller]

this is a bit strange, it seems I need to figure out a method to avoid the #ifdef LV_HAVE_NEON when LV_HAVE_NEONV8 is defined, but I must not have an #if… LV_HAVE_NEONV8 line, otherwise the build system assumes there's an neonv8 kernel

[argilo]

Why do you need to avoid building the neon kernel if neonv8 is defined?

I didn't think that made sense in #668 so I removed the nested #ifdefs, which weren't working to begin with.

[marcusmueller]

Because on arm64 machines, the neon kernel malfunctions:
https://github.com/gnuradio/volk/actions/runs/6617156936/job/17972909894?pr=680#step:3:2492

[argilo]

Ah. That seems like a bug that should be fixed.

[marcusmueller]

https://github.com/gnuradio/volk/actions/runs/6617156936/job/17972917000?pr=680#step:3:2453 Seeing that on our armv7 machine it doesn't run at all, do we test that Neon non-v8 kernels on anything, @jdemel ?

[argilo]

In #668 I found that nested ifdefs prevent the neon kernel from running even on 32-bit ARM, so it's possible it's broken on 32-bit ARM too.

[argilo]

Yep, it's broken. Change inputPtr += 4 to inputPtr += 8 and the kernel works fine.

[argilo]

Seeing that on our armv7 machine it doesn't run at all, do we test that Neon non-v8 kernels on anything, @jdemel ?

I too noticed that. It seems on the armv7 build, NEON is not detected at all. Perhaps a bug in platform detection?

[argilo]

By the way, neon is slower than generic on my Raspberry Pi, 2345.84 ms vs. 1977.6 ms.

[marcusmueller]

Since that Pi and maybe an E310 would be the main target for that kernel: should we maybe just eradicate both?

[argilo]

Yeah, I'd say get rid of it.

As far as I can tell, it's been broken since it was created in 2014 (158a6b2). It only correctly swaps the first two integers in the input vector, so I can't imagine it's ever done anyone any good.

[jdemel]

https://github.com/gnuradio/volk/actions/runs/6617156936/job/17972917000?pr=680#step:3:2453 Seeing that on our armv7 machine it doesn't run at all, do we test that Neon non-v8 kernels on anything, @jdemel ?

Unfortunately, no. If you happen to find some CI infrastructure for this, please add it. I didn't. We used to test these when TravisCI was still working.

[jdemel]

LGTM. The discussion concluded that these kernels were always broken.

[jdemel]

I'll close #606 after this PR is merged because this PR supersedes #606 . Thanks for working through this issue.