porting @Microsoft SPTAG (with native aliases enabled): missing __mmask32 __mmask64 _mm512_setzero_ps _mm512_cvtepi32_ps _mm512_extractf32x8_ps _mm512_cmpgt_epi16_mask

[pabs3]

While porting @microsoft SPTAG to use SIMDe (with native aliases enabled), I found that there are several missing functions/definitions. As suggested in the README.md I am reporting them here for prioritisation. There are some missing native aliases and missing variants of existing functions:

• simde_ variants defined but not native aliases
  • __mmask32
  • __mmask64
  • _mm512_setzero_ps
• _mm512_cvtepi32_ps: missing but _mm512_cvtepu32_ps exists
• _mm512_extractf32x8_ps: missing but _mm512_extractf32x4_ps exists
• _mm512_cmpgt_epi16_mask: missing but _mm512_cmpgt_epi8_mask exists

I need the native aliases because @microsoft requires signing a CLA, so I won't be submitting a pull request, so I want my patch to be relatively compatible with any changes that are made upstream to the intrinsics.

[bastien-roucaries]

Hi we need it for debian side packaging...

[mr-c]

Thanks for the report. There is a guide to adding new instructions at https://github.com/simd-everywhere/simde/wiki/Implementing-a-New-Function

[pabs3]

Update: _mm512_setzero_ps now exists since commit c900d5e

[bastien-roucaries]

ping ?

[mr-c]

Hello @bastien-roucaries There is a guide to adding new instructions at https://github.com/simd-everywhere/simde/wiki/Implementing-a-New-Function

Please let me know if you want assistance with working on this issue, I would be happy to help!

[mr-c]

@pabs3 Did you see that simde__mmask32, simde__mmask64, and simde_mm512_setzero_ps are implemented?

[pabs3]

@mr-c this issue isn't fully completed because the native aliases __mmask32 and __mmask64 don't exist.
I note that the __mmask8 and __mmask16 native aliases do exist though.

Thanks for implementing _mm512_cvtepi32_ps, _mm512_extractf32x8_ps, _mm512_cmpgt_epi16_mask in commit bf1fbae
and thanks to @EleonoreMizo for adding _mm512_setzero_ps in commit c900d5e.

[mr-c]

@mr-c this issue isn't fully completed because the native aliases __mmask32 and __mmask64 don't exist.
I note that the __mmask8 and __mmask16 native aliases do exist though.

Whoops I misunderstood. Did you see the note about those types in

simde/simde/x86/avx512/types.h

Lines 501 to 514 in 8b4e375

	/* These are really part of AVX-512VL / AVX-512BW (in GCC __mmask32 is
	* in avx512vlintrin.h and __mmask64 is in avx512bwintrin.h, in clang
	* both are in avx512bwintrin.h), not AVX-512F. However, we don't have
	* a good (not-compiler-specific) way to detect if these headers have
	* been included. In compilers which support AVX-512F but not
	* AVX-512BW/VL (e.g., GCC 4.9) we need typedefs since __mmask{32,64)
	* won't exist.
	*
	* AFAICT __mmask{32,64} are always just typedefs to uint{32,64}_t
	* in all compilers, so it's safe to use these instead of typedefs to
	* __mmask{16,32}. If you run into a problem with this please file an
	* issue and we'll try to figure out a work-around. */
	typedef uint32_t simde__mmask32;
	typedef uint64_t simde__mmask64;

If there is a specific compiler version / architecture combination that you are using, and for which you need the native types defined, I think that would be straightforward to add

[pabs3]

I did see that note, it sounds complicated.

When I was testing this I was on Debian bookworm amd64 with GCC 12. My intention was to enable porting SPTAG from amd64 to all of the Debian architectures, probably starting with arm64. Since bookworm is in the freeze, this will likely be something for trixie.

In that situation #define __mmask32 simde__mmask32 was enough to workaround __mmask32 being missing. Likewise for __mmask64. See the link to the SPTAG patch above.

PS: since you are the Debian maintainer of simde too, an upload to Debian experimental would be appreciated so I can work on this further.

[mr-c]

Sure, I can upload https://github.com/simd-everywhere/simde/releases/tag/v0.7.4-rc3 to Debian experimental, but it won't have all of the new functions you need; however you could copy them from bf1fbae

[pabs3]

Maybe wait until that commit has entered a release candidate.

[mr-c]

@pabs3 done: https://tracker.debian.org/news/1430405/accepted-simde-074rc4-0exp-source-into-experimental/

[pabs3]

This bug should still be open because of the native aliases for __mmask32 and __mmask64 are probably still missing? Thanks for the upload though, I'll be able to work on SPTAG now by adding some defines for __mmask32 and __mmask64.

…

-- bye, pabs https://bonedaddy.net/pabs3/

[mr-c]

@pabs3 I'm testing d850b83 to provide __mask32 and __mask64 now

[mr-c]

@pabs3 d850b83 has been merged! It'll be in the next rc snapshot (perhaps that will be the real release of 0.7.4 ??)

[mr-c]

@pabs3 whoops, that was my mistake; I've queued up a fix