Correcto, int arg debe convertirse en inmediato en ambos casos, por lo que debe ser una constante de tiempo de compilación después de la propagación constante.

Y sí, no hay razón para usar la versión sin enmascaramiento del C intrínseco para la versión AVX-512VL en C; solo tiene sentido tener _mm256_mask_extractf32x4_ps y _mm256_maskz_extractf32x4_ps .

En asm, es posible que desee la versión AVX-512 porque se necesita una codificación EVEX para acceder a ymm16..31 , y solo VEXTRACTF32X4 tiene una codificación EVEX. Pero, en mi opinión, esto es algo que su compilador de C debería poder cuidar por usted, independientemente de lo intrínseco que escriba.

Si su compilador optimiza los intrínsecos, sabrá que está compilando con AVX-512 habilitado y usará cualquier orden aleatorio que le permita trabajar con los registros que eligió durante la asignación de registros. (por ejemplo, clang tiene un optimizador de reproducción aleatoria muy agresivo, que a menudo usa instrucciones diferentes o convierte las mezclas aleatorias en mezclas más baratas cuando es posible. O, a veces, frustra los esfuerzos para escribir un código más inteligente que el que ofrece el optimizador de reproducción aleatoria).

Pero algunos compiladores (especialmente MSVC) no optimizan los intrínsecos, ni siquiera hacen una propagación constante a través de ellos. Creo que Intel ICC también es así. (No he mirado ICX, su compilador más nuevo basado en clang/LLVM). Este modelo hace posible usar los intrínsecos AVX-512 sin decirle al compilador que puede usar las instrucciones AVX-512 por sí solo. En ese caso, compilar _mm256_extractf128_ps en VEXTRACTF32X4 para permitir el uso de YMM16..31 podría ser un problema (especialmente si no hubiera otras instrucciones AVX-512VL en el mismo bloque, o que definitivamente se ejecutarán si esta lo hiciera).