Compilation for x86 x86_64 without AVX

[lisicky]

Hi! I have faced a problem when compilation for x86 or x86_64 without AVX emits an error. It happens because there isn't a restriction for a compiler not to compile a code with AVX intrinsics when that feature is not available. So I have prepared the fix for that case, and I would appreciate it if you check this PR.

[vincenthz]

Hi, thanks for the contribution, with which compilation flags do you come across this failure ?

The code is playing maybe a bit loose with the definitions of the flags / what they mean, but the intent was to add runtime detection of cpu features (although hit a roadblock on how to do this with stable rust) so that the code is there for all platform (avx, avx2, ...) but only used when it's been detected and have the fastest implementation regardless of cpu compilation flags.

[lisicky]

@vincenthz I was trying to compile it for android x86 when I got the error. mod avx2 is always compiled if you compile for x86, even if you do it without AVX2 support.

cryptoxide/src/hashing/blake2/mod.rs

Lines 15 to 16 in 9d22605

	#[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
	mod avx2;

Anyway #[cfg attribute does all stuff in compile time, and there is a case when you compile the lib with AVX2 support, and if you try to execute that code on a machine with only AVX or without SIMD instructions at all, you will get SIGILL or another error depends on an environment you run on.

Because in the code below, HAS_AVX2 will be compiled as true even if a cpu doesn't have AVX2 instruction set because the current implementation of cryptoxide forces to use AVX and AVX2 features because without it cryptoxide won't compile for x86.

cryptoxide/src/hashing/blake2/mod.rs

Lines 113 to 120 in 9d22605

	#[cfg(target_feature = "avx2")]
	const HAS_AVX2: bool = true;
	#[cfg(not(target_feature = "avx2"))]
	const HAS_AVX2: bool = false;
	if HAS_AVX2 {
	return avx2::compress_b(&mut self.h, &mut self.t, buf, last);
	}

And my PR is an attempt to prevent the cases I described above. I hope we will reach a consensus on this issue.

[renanvalentin]

I found a similar issue when building a lib using rust-android-gradle:

/cryptoxide-0.4.2/src/hashing/blake2/avx2.rs:59:17
    |
59  |             a = _mm256_add_epi64(a, $m);
    |                 ^^^^^^^^^^^^^^^^ not found in this scope
...
320 |     ROUND!(9, load9!());
    |     ------------------- in this macro invocation
    |
    = note: this error originates in the macro `G` which comes from the expansion of the macro `ROUND` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this function
    |
1   | use core::arch::x86::_mm256_add_epi64;

[lisicky]

Hi @vincenthz ! I also made a new PR #40 . Could you check it ? It's important to us to have compatibility with x86 machines.

[vincenthz]

I'm not certain this is the right way to go at this stage, but to avoid further delay, this is the safest path right now until I figure really what to do with compilation and autodetection.

I've fiddled with flags to try to reproduce the build error, but to not available. So i'm totally sure that support 32 bits x86 (which it seems that's what it is) is actually useful to anything these days, and not the artifact of a typical default generator of android package targets.