Possible incorrect inclusion of AVX2 instructions when not enabled about libsimdpp HOT 3 CLOSED

FWIW, I expected the behavior to be to emit pandn i.e.:

__m128i _mm_andnot_si128 (__m128i a, __m128i b)

from libsimdpp.

Hi, I suspect that the issue is not related to libsimdpp itself as AVX equipped CPU should support the instruction in question.

Processors that support AVX also support the version of vpandn that operates on XMM registers (ref). The v in vpandn only indicates that the instruction is using VEX prefix, which is a separate instruction encoding scheme introduced on AVX. Most SSE-SSE4 instructions are available in VEX-prefixed form on AVX. AVX2 is a requirement only for instructions that operate on YMM registers.

Using non VEX instructions along with VEX instructions introduces a large performance penalty, so compilers try to use vpandn for _mm_andnot_si128 instead of older pandn from AVX onwards.

Could you please check whether running any code that just uses __m128i _mm_andnot_si128 (__m128i a, __m128i b) works on your CPU when that code is compiled for AVX? Not being able to run 128-bit vpandn instruction on AVX is very strange. The fact that CAN_RUN_X86_AVX test succeeded is even more strange, because that means that it's possible to run certain instructions with VEX prefixes but not others.

from libsimdpp.

Upon further investigation, I cannot reproduce the SIGILL. The only plausible explanation I have is that while moving some source code around I brought along an old binary and failed to cleanly recompile before trying to execute it. Everything is copacetic now.

My primary confusion came from looking at the assembly and the faulty thinking that vpandn was an AVX2 instruction. The Intel Intrinsics Guide doesn't list a vpandn when filtered to AVX, heh. Thanks for the pointer to http://www.felixcloutier.com/x86/, I'll be sure to check there before filing any more errant bugs 😬.

Thanks for your time and the library!

from libsimdpp.