SSE4.1 support cannot be enabled on machines with AVX

[stefantalpalaru]

It is due to this check:

basis_universal/encoder/basisu_kernels_sse.cpp

Lines 26 to 27 in 8903f6d

	#if __AVX__ || __AVX2__ || __AVX512F__
	#error Please check your compiler options

Looks like some unfortunate refactoring artefact from old code that supported more than one SIMD type.

[richgel999]

If AVX || AVX2 || AVX512F are defined here then the generated SSE code won't execute on very old (ancient!) CPU's that don't support AVX. That's why these macros are here. I'll double check that this still works, though.

[richgel999]

I've verified that SSE supports works as intended under Windows and Linux. Can you describe what you're doing that's causing these code gen sanity checks to trigger? Your options are probably not the same as the ones used to compile the tool.
I think it's fine to remove them if you're ok with the generated code not working on old CPU's. Perhaps I can put these checks in a guard.

[stefantalpalaru]

If __AVX__ || __AVX2__ || __AVX512F__ are defined here

Those are always defined by the compiler, on CPUs that support those features.

I've verified that SSE supports works as intended under Windows and Linux.

Does that CPU support AVX? Try replicating it on a VPS, with a more modern CPU.

Can you describe what you're doing that's causing these code gen sanity checks to trigger?

Trying to enable SSE4.1 by compiling the software on a CPU that supports AVX.

See also: https://bugs.gentoo.org/892727

Your options are probably not the same as the ones used to compile the tool.

cmake -DBUILD_X64=ON -DOPENCL=ON -DSSE=ON -DZSTD=ON

if you're ok with the generated code not working on old CPU's

No such risk. Runtime CPU feature check takes care of that.

The code I'm removing with the related PR, from 2 months ago, is a redundant and buggy compile-time check. No functionality will be lost.

[richgel999]

Odd. I'm going to merge your PR - I don't see any harm in it. Thanks!