solardiz
commented
3 months ago Also subtly relevant, our ppc_cpuid.c is currently Linux-specific and when run on non-Linux it claims everything is supported, often resulting in a build that does not actually work on the host. Maybe we should at least have ppc_cpuid.c stop reporting anything but PPC_FEATURE_HAS_ALTIVEC (or anything at all?) in 32-bit non-Linux builds. Someone building for 32-bit is either on an old CPU that may at best have the original AltiVec, or is doing a sub-optimal build on 64-bit hardware anyway (in which case we'd better improve our 64-bit detection first). Another way to fix this would be to move away from our manual CPU type detection to using -march=native.
Given the original issue here (us only supporting SIMD on POWER8+ now), if ppc_cpuid.c reports only PPC_FEATURE_HAS_ALTIVEC (or anything less than all 1's) that will currently mean a non-SIMD build. So it can as well report all 0's for the same effect until this issue is fixed.
Apparently, during the mass non-x86 SIMD work in GSoC 2015 we got extensive support for AltiVec as available on POWER8, but at the same time broke the more limited support we had (and still have in the core tree, for bitslice DES) for pre-POWER8 AltiVec. Due to Jim's recent work, we're now falling back to a fully non-SIMD build on POWER7 and below.
We should re-add support for AltiVec as available on pre-POWER8 CPUs, when building on/for those. Apparently, the most difficult aspect here is either defining a 64-bit SIMD add (for SHA-512) through 32-bit SIMD add and handling of the carry between odd and even 32-bit halves with extra intrinsics, or having just those formats that need this capability (thus, anything based on SHA-512) build without SIMD.