Add bfloat16 based dot and conversion with single/double

[Guobing-Chen]

1. Added bfloat16 based dot as new API: shdot
2. Implemented generic kernel and cooperlake-specific (AVX512-BF16) kernel for shdot
3. Added 4 conversion APIs for bfloat16 data type <=> single/double: shstobf16 shdtobf16 sbf16tos dbf16tod
   shstobf16 -- convert single float array to bfloat16 array
   shdtobf16 -- convert double float array to bfloat16 array
   sbf16tos -- convert bfloat16 array to single float array
   dbf16tod -- convert bfloat16 array to double float array
4. Implemented generic kernels for all 4 conversion APIs, and cooperlake-specific kernel for shstobf16 and shdtobf16
5. Update level1 thread facilitate functions and macros to support multi-threading for these new APIs
6. Fix Cooperlake platform detection/specify issue when under dynamic-arch building
7. Change the typedef of bfloat16 from unsigned short to more strict uint16_t

[Guobing-Chen]

Some more information about the 4 conversion APIs in this PR:
OpenBLAS needs these conversion APIs as we should help our users to better use OpenBLAs's bfloat16 BLAS APIs. There are no any libs in community that provide capability to convert bfloat16 from/to single/double, we cann't just leave it to our users to do the implementation, instead we can provide a professional implementation with best performance.
Another reason that we need these conversion APIs is that for those platforms not support bfloat16 hardware support, the fall-backed generic kernels need these conversion APIs to convert back to single data type and then calculating with s based BLAS APIs.

[conradsnicta]

I'm not sure it's a good idea to call "bfloat16 based dot" as shdot. Perhaps bf16dot would be more appropriate.

The sh prefix in shdot indicates (or strongly suggests) "half single precision". The bfloat16 type is certainly not "half single precision". Instead, it's a mutated version of fp32.

The proper "half single precision" type is already defined in the IEEE 754-2008 standard: https://en.wikipedia.org/wiki/Half-precision_floating-point_format. This is not the same as bfloat16.

Related discussion: #2767. Extract from comment by @mgates3: "... we're proposing to move away from single letter precisions, so likely will never standardize on h for half" and "... differentiating IEEE half and bfloat16 half with one letter is confusing".

[martin-frbg]

If you are quoting from #2767, you will have seen how the SH.. names came to be. Please comment there if you are not satisfied with Edelsohn's dictum.

[martin-frbg]

Holding back on this one as it appears to have caused some collateral damage (SIGSEGV in regular single precision) on ppc.

[Guobing-Chen]

Holding back on this one as it appears to have caused some collateral damage (SIGSEGV in regular single precision) on ppc.

Anything I can do to help? Unfortunately that I don't have a PPC machine to reproduce.

[martin-frbg]

Already trying to track it down in the unicamp OpenPOWER minicloud, just wanted to let you know that it has nothing to do with the ongoing discussion about names.

[Guobing-Chen]

Well received, thanks much for the information.

[martin-frbg]

Seems to have been unrelated breakage in my build environment, sorry for the delay.