_mm512_bitshuffle_epi64_mask implementation

[Wunkolo]

Typing from an Icelake machine(i7-1065G7)!
I can peck at this again, even if it ends up slower in the 2D case it'll still be interesting as it can also solve the more general case of trying to interleave the bits of three input variables in parallel possibly much faster than a series of pext/pdep.

Here's measured latency data from uops.info for vpshufbitqmb.

Instruction									Lat		TP			Uops	Ports
VPSHUFBITQMB (K, K, XMM, M128)	AVX512EVEX	[1;8]	1.00 / 1.00	3		1*p0+1*p23+1*p5
VPSHUFBITQMB (K, K, XMM, XMM)	AVX512EVEX	[1;8]	1.00 / 1.00	2		1*p0+1*p5
VPSHUFBITQMB (K, K, YMM, M256)	AVX512EVEX	[1;8]	1.00 / 1.00	3		1*p0+1*p23+1*p5
VPSHUFBITQMB (K, K, YMM, YMM)	AVX512EVEX	[1;8]	1.00 / 1.00	2		1*p0+1*p5
VPSHUFBITQMB (K, K, ZMM, M512)	AVX512EVEX	[1;8]	1.00 / 1.00	3		1*p0+1*p23+1*p5
VPSHUFBITQMB (K, K, ZMM, ZMM)	AVX512EVEX	[1;8]	1.00 / 1.00	2		1*p0+1*p5
VPSHUFBITQMB (K, XMM, M128)		AVX512EVEX	6		1.00 / 1.00	3		1*p0+1*p23+1*p5
VPSHUFBITQMB (K, XMM, XMM)		AVX512EVEX	6		1.00 / 1.00	2		1*p0+1*p5
VPSHUFBITQMB (K, YMM, M256)		AVX512EVEX	6		1.00 / 1.00	3		1*p0+1*p23+1*p5
VPSHUFBITQMB (K, YMM, YMM)		AVX512EVEX	6		1.00 / 1.00	2		1*p0+1*p5
VPSHUFBITQMB (K, ZMM, M512)		AVX512EVEX	6		1.00 / 1.00	3		1*p0+1*p23+1*p5
VPSHUFBITQMB (K, ZMM, ZMM)		AVX512EVEX	6		1.00 / 1.00	2		1*p0+1*p5			

compared to pext

Instruction						Lat		TP			Uops	Ports
PEXT (R32, R32, M32)	BMI2	[3;8]	1.00 / 1.00	2		1*p1+1*p23
PEXT (R32, R32, R32)	BMI2	3		1.00 / 1.00	1		1*p1
PEXT (R64, R64, M64)	BMI2	[3;8]	1.00 / 1.00	2		1*p1+1*p23
PEXT (R64, R64, R64)	BMI2	3		1.00 / 1.00	1		1*p1	

and pdep

Instruction						Lat		TP			Uops	Ports
PDEP (R32, R32, M32)	BMI2	[3;8]	1.00 / 1.00	2	1*p1+1*p23
PDEP (R32, R32, R32)	BMI2	3		1.00 / 1.00	1	1*p1
PDEP (R64, R64, M64)	BMI2	[3;8]	1.00 / 1.00	2	1*p1+1*p23
PDEP (R64, R64, R64)	BMI2	3		1.00 / 1.00	1	1*p1	

[Forceflow]

Looking really good. Don't forget to run libmorton_test to easily spot errors.

[Wunkolo]

Got a first MVP implemented now for encoding and decoding. It's give or take in terms of its performance against pexp/pdep methods at the moment. So I'll be exhausting some optimization ideas and then this branch will be ready for a merge/review.

I found that the usual _mm512_shuffle_epi8's 128-bit lane boundaries limited the 3D options and I had to use AVX512_VBMI 's _mm512_permutexvar_epi8 to get a true shuffle to happen, adding to the AVX512 subset requirements. Going to try and limit some of this so that it can appeal to the smallest subset of AVX512 feature sets.

[Forceflow]

Cool - tell me when you want me to review/merge