NEON intrinsics cannot be used when compiling for an ARM CPU without
hardware floating point support, e.g. the Debian armel port. In this
case arm_neon.h cannot even be included as it causes an #error.
[Based on a patch by Adrian Bunk <bunk@debian.org>, but changed to check
for __ARM_FP instead of !__SOFTFP__ to be consistent with arm_neon.h,
and added a comment.]
All 64bit PowerPC CPUs handle unaligned accesses reasonably fast, so
set UNALIGNED_ACCESS_IS_FAST.
Decompression of the snappy html test case is almost 50% faster on
POWER9 with this patch applied.
Now that we detect CPU features on 32-bit x86, allow the SSE2
implementation of Adler-32 to be selected at runtime based on the
presence of the SSE2 feature.
Replace COMPILER_SUPPORTS_TARGET_INTRINSICS with macros for the
individual features, since COMPILER_SUPPORTS_TARGET_INTRINSICS was
x86-specific and would cause confusion when we try to use intrinsics in
'target' functions for other architectures.
With clang 3.9:
warning: macro expansion producing 'defined' has undefined
behavior [-Wexpansion-to-defined]
Just eliminate the tests for clang and icc; they shouldn't be necessary.
It was reported that API symbols were being "exported" from the static
library built with MSVC, causing them to remain exported after being
linked into another program. It turns out this was actually a problem
outside of MSVC as well. The solution is to always build the static and
shared libraries from different object files, where the API symbols are
exported from the shared library object files but not from the static
library object files.
Reported-by: Joergen Ibsen <ji@ibse.dk>
* Bring in common headers and program code from xpack project
* Move program code to programs/
* Move library code to lib/
* GNU89 and MSVC2010 compatibility
* Other changes
