- XXH_SIZE_OPT is a value from 0-2 which indicates how much xxHash
   should care about code size, default 1 for -Os/-Oz, default 0
   otherwise
 - XXH_NO_STREAM disables the streaming API.
 - These two interact: if XXH_SIZE_OPT == 2 and XXH_NO_STREAM is not
 defined, XXH32 and XXH64 use the streaming API for single shot
    - TODO: apply this to XXH3 as well

since some versions are buggy.

Use `_Static_assert` instead, which is part of the C11 language.

do no longer depend on `<assert.h>` for XXH_STATIC_ASSERT

It seems that using the streaming API is not beneficial on GCC so it
isn't worth the complexity.

Uses `#pragma push_macro`/`#pragma pop_macro` instead of assuming that
`__APPLE_ALTIVEC__` can be defined safely.

Safer and less hacky fix for #668.

Properly fix altivec namespace collisions

Introduce XXH_SIZE_OPT and XXH_NO_STREAM

Remove duplicated definition of XXH3_128bits

Fix #689

Removed windows-2016 from ci.yml

tipi.build instructions

For details, see issue #695.

If filename contains special character (\n, 0x0a, LF),

- Put '\' (0x5c) at the beginning of the line.
- Escape special character by '\'.

Fix issue #695

Build fix for Haiku

Use inline assembler for Power/IBM XL Compiler

This is PR #699 from @t-mat,
which was blocked by a file permission issue.
Retrying it here.

test filename-escape

avoid add_compile_definitions for cmake < v3.12

for closer correspondence with XXH3_hashLong64_f definition

answering #717

Signed-off-by: Ghasem Ramezani (Work) <gh.ramazani@arad.co.net>

just more cmake v2.8.12 tests

CPack Added

Streamed loads (`vmovntdqa`) don't provide any benefit over normal
aligned loads (`vmovdqa{8|16|32|64}`) but prevent GCC/Clang from
micro-fusing the loads with the ALU wasting code size.

Replace lane cross `vpbroadcastq` with `vpsubq`

Remove stream loads and slightly improve avx512 seed generation

Since GNU make invokes `shell` by default, it doesn't support brace expansion.
This changeset expands the braces to fix the issue.

main() introduces new variable algoBitmask which represents the algorithm(s)
which will be accepted by the CLI.
main() also sets suitable algoBitmask for exename and passes it to
XSUM_checkFiles().
The default algoBitmask is algo_bitmask_all which accepts all xxh algorithms.

XSUM_checkFiles() passes algoBitmask to XSUM_checkFile().

XSUM_checkFile() sets algoBitmask to XSUM_parseFileArg->algoBitmask and
invokes XSUM_parseFile1().

XSUM_parseFile1() passes algoBitmask to XSUM_parseLine().

XSUM_parseLine() passes algoBitmask to XSUM_parseLine1().

XSUM_parseLine1() calles XSUM_algoBitmask_Accepts() to check
actual xxh algorithm of the line and algoBitmask matches or not.

Fix: brace expansion

Fix issue #724

list available algorithms

See also:
actions/runner-images#5583

Remove macOS-10.15 from ci.yml

blind fix for fallthrough on icc

Optimize XXH3_accumulate_512_neon

Fix typos found by codespell

Run command "make clean cppcheck".

---- static analyzer - cppcheck ----
cppcheck . --force --enable=warning,portability,performance,style --error-exitcode=1 > /dev/null
cli/xsum_os_specific.c:220:9: style: The scope of the variable 'ret' can be reduced. [variableScope]
    int ret;
        ^
cli/xsum_sanity_check.c:571:19: style: Condition 'len>0' is always true [knownConditionTrueFalse]
    } else if (len>0) {
                  ^
cli/xsum_sanity_check.c:569:13: note: Assuming that condition 'len==0' is not redundant
    if (len == 0) {
            ^
cli/xsum_sanity_check.c:571:19: note: Condition 'len>0' is always true
    } else if (len>0) {
                  ^
tests/bench/benchHash.c:112:55: error: Uninitialized variables: result.internal_never_ever_use_directly, result.error_result_never_ever_use_directly, result.error_tag_never_ever_use_directly [uninitvar]
    BMK_runTime_t const runTime = BMK_extract_runTime(result);
                                                      ^
tests/bench/benchHash.c:107:12: note: Assuming condition is false
    while (!BMK_isCompleted_TimedFn(txf)) {
           ^
tests/bench/benchHash.c:107:12: note: Assuming condition is false
    while (!BMK_isCompleted_TimedFn(txf)) {
           ^
tests/bench/benchHash.c:107:12: note: Assuming condition is false
    while (!BMK_isCompleted_TimedFn(txf)) {
           ^
tests/bench/benchHash.c:112:55: note: Uninitialized variables: result.internal_never_ever_use_directly, result.error_result_never_ever_use_directly, result.error_tag_never_ever_use_directly
    BMK_runTime_t const runTime = BMK_extract_runTime(result);
                                                      ^
tests/bench/benchfn.c:95:12: error: Uninitialized variable: outcome.error_result_never_ever_use_directly [uninitvar]
    return outcome;
           ^
tests/collisions/main.c:209:14: style: Same expression on both sides of '<='. [duplicateExpression]
    assert(m <= m);
             ^
make: *** [Makefile:387: cppcheck] Error 1

Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>

[err] Dynamic exception type: std::runtime_error
std::exception::what: can not create git repository [-3] - config value
  'safe.directory' was not found
[err] Something went wrong, for help on your issue, we could enjoy getting
  your report at https://tipi.build/#contact
Error: Process completed with exit code 1.

Apply the workaround from Yannic (#744)
on github CI workflow

Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Yannic Staudt <yannic@tipi.build>

ci: fix tipi build error on github CI workflow

`vpshufd` was just to essentially implement `dst >> 32` which can (and
should) be done with `vpsrlq`.

`XXH3_{32|64|128}bits` throughput seems to be limitted by a port_5
bottleneck and under-uses port_0.

Hashing 1mb in a loop 100000 times with `vpshufd`:
    x86-64-v4:
         5,363,095,005      cycles
         5,195,740,817      port_0
            17,104,516      port_1
         5,358,811,641      port_5
    x86-64-v3:
         7,954,143,671      cycles
         6,610,562,251      port_0
         7,405,810,291      port_1
         7,474,008,658      port_5

`vpshufd` on x86-64-v3 only runs on port_5 (and for x86-64-v4
only runs on port_5 when used with `zmm` registers). `vpsrlq` can
run on port_{0|1} (port_0 only for `zmm`) which helps to
alleviate this bottleneck.

Hashing 1mb in a loop 100000 times with `vpsrlq`:
    x86-64-v4:
         5,305,723,460      cycles
         5,246,052,997      port_0
            17,759,291      port_1
         5,303,090,711      port_5
    x86-64-v3:
         7,852,139,442      cycles
         6,950,368,526      port_0
         7,301,134,590      port_1
         7,215,987,871      port_5

which in general gets a better port distribution and results in
slightly better times.

Note the sse2 accumulate also would benefit from shifting uops from
port5 -> port0

    x86-64-v2 with `pshufd`:
        13,128,826,786      port_0
        15,014,228,537      port_1
        14,801,410,216      port_5

    x86-64-v2 with `psrlq`:
        13,899,468,407      port_0
        14,774,790,828      port_1
        14,555,300,082      port_5

But since `pshufd` has a 3-term encoding and `psrlq` only has a 2-term
encoding, using `psrlq` causes an extra `movdqa` in codegen which
is a net-negative (at least on Icelake benchmarks).

Benchmarking on Icelake this commit results in the following
improvements:

NB: The avx2 changes where also benchmarked on Icelake which is
not really ideal. Although note that Icelake (unlike native
x86-64-v3 hardware has a faster `vpshufd` (port_{1|5} vs
just port_5) so hopefully anything skewed by incorrect hardware
was infavor of the original implementation).

Signed truncation of len gets worse codegen so keep it unsigned.

Signed codegen for loop bound on x86-64-v4:
```
     mov    %esi,%ecx
     lea    0xe(%rsi),%r10d
     dec    %ecx
     cmovns %ecx,%r10d
     sar    $0x4,%r10d
```

Unsigned codegen for loop bound on x86-64-v4:
```
    lea    -0x1(%rsi),%ecx
    mov    %ecx,%r9d
    shr    $0x4,%r9d
```

Neither Clang nor GCC <= 11.2 get this so seems worth it to do by hand
so save the instruction. Not really on the critical path so only minor
perf changes.

Hashing 8kb On Icelake with 2x vpxor:

     5,451,267,137      cycles
     5,371,545,012      p0
       301,488,579      p1
     5,420,594,430      p5
       450,583,083      p6

Hashing 8kb On Icelake with 2x vpternlogd:

     5,400,583,791      cycles
     5,329,872,021      p0
       305,543,626      p1
     5,372,500,814      p5
       446,853,381      p6

Update GitHub Actions

Implement intrinsic code for ARM SVE. In this patch, it seems that there
is no improvement. Further optimization will be contained in the later
patch set.

SCALAR implementation (default)
 ===  benchmarking 4 hash functions  ===
benchmarking large inputs : from 512 bytes (log9) to 128 MB (log27)
xxh3   ,  2718,  3093,  3151,  3187,  3217,  3232,  3238,  3223,  3190,  3240,  3241,  3222,  3238,  3049,  2253,  2113,  2102,  2117,  2132
XXH32  ,  1499,  1520,  1538,  1543,  1543,  1545,  1547,  1535,  1486,  1487,  1484,  1468,  1484,  1435,  1231,  1183,  1184,  1185,  1187
XXH64  ,  2632,  2874,  3017,  3092,  3132,  3143,  3155,  3122,  2990,  2994,  2998,  3000,  3006,  2842,  2121,  1838,  1833,  1811,  1839
XXH128 ,  2435,  2872,  3024,  3121,  3187,  3219,  3234,  3222,  3221,  3225,  3225,  3227,  3227,  3034,  1962,  1789,  1866,  1871,  1874

Intrinsic SVE512 implementation
 ===  benchmarking 4 hash functions  ===
benchmarking large inputs : from 512 bytes (log9) to 128 MB (log27)
xxh3   ,  1903,  2313,  2469,  2568,  2631,  2663,  2683,  2662,  2673,  2678,  2679,  2678,  2676,  2584,  2236,  2173,  2173,  2163,  2183
XXH32  ,  1326,  1436,  1495,  1523,  1535,  1543,  1547,  1536,  1505,  1506,  1504,  1507,  1508,  1446,  1246,  1193,  1194,  1194,  1167
XXH64  ,  2510,  2802,  2977,  3071,  3121,  3136,  3156,  3126,  3041,  3047,  3050,  3050,  3048,  2890,  2043,  1944,  1944,  1945,  1955
XXH128 ,  1867,  2295,  2462,  2542,  2627,  2663,  2679,  2656,  2661,  2675,  2673,  2647,  2671,  2574,  2218,  2144,  2169,  2175,  2181

Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: Devin Hussey <easyaspi314@users.noreply.github.com>

Since the vector size of ARM64 SVE ranges from 128-bit to 2048-bit,
configure CI to run with each vector size.

Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>

Faster (better IPC) to make computation slightly more independent.

Results are from geometric mean of N = 6 runs.

Machine:
```
11th Gen Intel(R) Core(TM) i7-11850H @ 2.50GHz
```

CC:
```
gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
```

Bench Command:
```
// Change is only for 17-128 range.
$> ./benchHash xxh3 --mins=1 --maxs=256 --minl=0 --maxl=0
```

Aggregated Results for [17, 128] size range:
Times reported as geometric mean of all speedups.

Latency for small inputs of fixed size :
    - 1.073
Throughput small inputs of fixed size (from 1 to 256 bytes):
    - 1.173
Latency for small inputs of random size [1-N] :
    - 1.051
benchmarking random size inputs [1-N] :
    - 1.134

So roughly 5-17% improvement.

xxhash: support SVE by intrinsic code

fix issues reported by cppcheck

Missing space caused that github action doesn't work.

Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>

CI: fix missing space

Fixing tipi-build / Build as dependency CI step

XXH3_accumulate() handle the whole accumulating loop and architecture
optimized code is in the mini loop of 512 bytes. But it also causes
accessing memory frequently for the large block data.

Now make XXH3_accumulate() as architecture optimized code.

Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: Devin Hussey <easyaspi314@users.noreply.github.com>

With optimized full accumulating loop, the performance is improved
at least 2 times.

The ACC result needn't to save to stack in the full loop. And
instructions of prefetching data for SVE are also used.

Without this patch, the performance result is in below.
 ===  benchmarking 4 hash functions  ===
benchmarking large inputs : from 512 bytes (log9) to 128 MB (log27)
xxh3   ,  1904,  2315,  2468,  2580,  2640,  2670,  2682,  2673,  2677,  2663,  2683,  2688,  2686,  2591,  2241,  2181,  2191,  2048,  2048
XXH32  ,  1326,  1440,  1493,  1523,  1534,  1543,  1547,  1532,  1504,  1507,  1507,  1505,  1506,  1446,  1218,  1150,  1151,  1153,  1135
XXH64  ,  2511,  2795,  2975,  3068,  3120,  3125,  3154,  3128,  3034,  3045,  3052,  3053,  3053,  2842,  2050,  1853,  1848,  1853,  1853
XXH128 ,  1867,  2294,  2465,  2569,  2622,  2662,  2676,  2667,  2677,  2682,  2684,  2677,  2683,  2570,  2093,  2013,  2045,  2046,  2046

With this patch, the performance result is in below.
 ===  benchmarking 4 hash functions  ===
benchmarking large inputs : from 512 bytes (log9) to 128 MB (log27)
xxh3   ,  3681,  6007,  7803,  8954,  9875, 10411, 10703, 10505, 10670, 10794, 10812, 10804, 10205,  9923,  6279,  5927,  5967,  6022,  6062
XXH32  ,  1281,  1434,  1494,  1523,  1534,  1543,  1547,  1535,  1500,  1502,  1502,  1502,  1501,  1443,  1242,  1169,  1193,  1196,  1195
XXH64  ,  2497,  2801,  2961,  3074,  3092,  3136,  3155,  3123,  3031,  3037,  3040,  3037,  3033,  2847,  2102,  1955,  1967,  1974,  1971
XXH128 ,  3419,  5798,  7488,  8854,  9787, 10357, 10673, 10468, 10647, 10748, 10785, 10751, 10805,  9698,  6011,  5677,  5999,  6065,  6074

Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: Devin Hussey <easyaspi314@users.noreply.github.com>

Customize full accumulating loop for SVE

added macos-12 test to GH CI

No change to generated code, just suppresses the warning when using
stricter compiler checks.

Small improvement to x86 vectorized hashes and medium-sizes hash.

Minimal change but eliminates the NULL check if the attribute
is supported.

dispatch: Use __attribute__((constructor)) on XXH_setDispatch

Add install_libxxhash.includes to be able to install headers when
building and installing the static library

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

Fix typo found by codespell

http:// → https://

The issue link is in below.
#766

This issue occurs randomly. If we downgrade gcc optimization from "O3"
to "O2", this issue is gone.

Now use memory barrier to implement the same effect.

Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>

LLVM only at the moment.

Without LTO its the only way to inform the compiler that the pointer
does not become globally visible due to the function call.

1. Don't compute `nbRounds` and use len as upper bound in 129to240

Codegen was previously using the divide to truncate the lower-bits but
was shifting back for the actual loop.

Previous Codegen:
```
// XXH128_129to240:
shr    $0x5,%r15d
lea    -0x5(%r15),%r13d
shl    $0x5,%r13
...
```

which is totally unnecessary.
On aarch64 we are likewise able to eliminate some `lsl` instructions.

Similiar changes "should" make sense in the 64bit version but seemed
to always cause minor regressions for M1 so scrapped.

2. Add second accumulator in `XXH3_len_129to240_64b` to get a bit more
   out of OOE. Note, for aarch64 we have to add a `XXH_COMPILER_GUARD(acc)`
   in the final loop of `XXH3_len_129to240_64b`. Without it clang and
   gcc where unrolling the second loop and interleaving it with the first.
   This caused a LOT of unnecessary constant materialization (unique
   for each unrolled iteration).