Add run-time hardware detection of SSE,AVX,AVX2

[amkozlov]

There is a problem with clang version detection here: https://github.com/xflouris/libpll/blob/master/src/hardware.c#L26

due to the fact that there seems to be two parallel version numbering schemes...

E.g. on apple-sco, we have:

$ clang -v
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

$ echo | clang -dM -E - | grep clang
#define __VERSION__ "4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)"
#define __clang__ 1
#define __clang_major__ 8
#define __clang_minor__ 0
#define __clang_patchlevel__ 0
#define __clang_version__ "8.0.0 (clang-800.0.42.1)"

Presumably, one shouldn't rely on those predatory version numbers but use __has_builtin instead:

https://stackoverflow.com/questions/1617877/how-to-detect-llvm-and-its-version-through-define-directives

but ironically, this doesn't work for __builtin_cpu_supports

https://bugs.llvm.org//show_bug.cgi?id=25510

So I'm afraid the only workaround here would be to have additional checks for __clang_major__ 7 and 8 and corresponding __clang_minor__...

[xflouris]

@amkozlov : if I understand correctly, the preprocessor check for line 26 fails (i.e. clang version > 3.9.x) and as such, it attempts to use __builtin_cpu_supports which also fails for this particular version of clang?

[amkozlov]

@xflouris: exactly.

And to add to the confusion, LLVM is now changing the versioning scheme: http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html

so if I get it right, in just a couple of years we will have LLVM/clang v8.0.0 which is not the same as v8.0.0 we have right now.

[xflouris]

great :-( Maybe an easier solution would be to check for APPLE and force assembly code on it, instead of checking additional clang versions? I think Linux uses clang 3-4 (but I'm not really sure).

[amkozlov]

yes, probably that's the easiest solution