Sorry about the disorganized commit. :(
Yet again, I had to fix ARMv6. Clang went from ldm to ldrd which
also bus errors.
Therefore, I decided to fix the root problem and remove the
XXH_FORCE_DIRECT_MEMORY_ACCESS hack, using only memcpy.
This will kill alignment memes for good, and besides, it didn't
seem to make much of a difference.
Additionally, I added my better 128-bit long multiply
and applied DRY to XXH3_mul128_fold64. This also removes
the cryptic inline assembly hack.
Each method was documented, too (we need more comments).
Also, I added a warning for users who are compiling Thumb-1
code for a target supporting ARM instructions.
While all versions of ARM and Thumb-2 meet XXH3's base requirements,
Thumb-1 does not.
First of all, UMULL is inaccessible in the 16-bit subset. This means
that every XXH_mult32to64 means a call to __aeabi_lmul.
Since everything operation in XXH3 needs to happen in the Lo registers
plus having to setup r0-r3 many times for __aeabi_lmul, the output
resembles a game of Rush Hour:
$ clang -O3 -S --target=arm-none-eabi -march=armv4t -mthumb xxhash.c
$ grep -c mov xxhash.s
5472
$ clang -O3 -S --target=arm-none-eabi -march=armv4t xxhash.c
$ grep -c mov xxhash.s
2071
It is much more practical to compile xxHash with the wider instruction
sets, as these restrictions do not apply.
This doesn't warn if ARMv6-M is targeted; Thumb-1 is unavoidable.
Lastly, I removed the pragma clang loop hack which didn't work anymore
since the number of iterations can't be constant evaluated. Now, we
don't have 20 warnings when compiling for x86.
Clang was using ldmia and ldrd on unaligned pointers. These
instructions don't support unaligned access.
I also check the numerical value of __ARM_ARCH.
The VSX codepath is now working on POWER8 and is fully enabled.
The little endian code has been verified on POWER8E, although
a big endian machine was not available.
This uses vpermxor from POWER8 to shuffle on big endian.
There are a few other fixes as well to unify endian memes.
