openzl

Summary Optimize AArch64 Neon support functions and add Neon accelerated bitSplit floating-point encode/decode paths. This change: adds independent compile-time feature detection for Neon, DotProd, I8MM, SVE, SVE2, and SVE2 BitPerm; replaces the SVE2 BitPerm-based 128-bit mask extraction with native Neon implementations, using I8MM or DotProd when available and a baseline Neon fallback otherwise; adds a native 256-bit Neon SIMD wrapper backed by two 128-bit vectors; adds optimized Neon implementations for bf16, fp16, fp32, and fp64 encoders and decoders; preserves the existing scalar/reference implementations as fallbacks on non-Neon targets; adds negative-value round-trip tests for bf16, fp16, fp32, and fp64 to verify correct sign-bit handling. The optimized paths show substantial speedups on several tested AArch64 CPUs. Type of Change Performance improvement Test Plan Added round-trip coverage for negative bf16, fp16, fp32, and fp64 values to verify that encoding and decoding preserve the sign bit correctly. Validated the optimized encode/decode implementations against the existing reference behaviour. Performance was benchmarked using the enwik5 dataset on multiple AArch64 CPU cores by . The Neon implementations were compared against the reference implementations using both Clang-22 and GCC-16 builds. Decoder benchmarks showed improvements: Encoder performance varies by CPU/compiler combination: Clang-22 emitted essentially the same instructions as the auto-vectorized implementation but scheduled them differently and replaced some of the hinted intrinsics, while GCC-16 generally performed better by preserving those hints and following the intrinsic-defined instruction ordering more closely: Test Configuration Compiler: Clang-22, GCC-16 Build type: Release / benchmark build Platform(s): AArch64

xxhash issue reported upstream FYI What it shows The bug is in src/openzl/shared/xxhash.h: with XXH_FORCE_MEMORY_ACCESS == 1 (the default for GCC), XXH_read32/XXH_read64 read through a __attribute__((__aligned__(1))) typedef. That attribute lowers alignment but grants no __may_alias__, so the access is still a uint32_t/uint64_t lvalue. Reading memory whose effective type is something else (a float/double written through a sibling pointer) is UB under C 6.5p7, and GCC's TBAA is allowed to assume the store doesn't alias the load and hoist the load out of the loop — exactly the "code hoisting in MyMap_insert" you described. Reproduction (gcc-16, -O2 -march=x86-64-v3) XXH_read32 : hoisted(aliased)=0000000000000000 correct(memcpy)=00000010420b0000 MISMATCH (load hoisted) XXH_read64 : hoisted(aliased)=0000000000000000 correct(memcpy)=d041600000000000 MISMATCH (load hoisted) The generated code confirms the hoist: MyMap_insert_u32: movl (%rdi), %eax # load key_slot ONCE, before the loop movl $0x42bd0000,(%rsi) # store final float salq $6, %rax # acc = pre-loop value ITERS ret It reproduces at -O2/-O3, with and without -march=x86-64-v3 — the driver is TBAA + loop-invariant motion, v3 is just your trigger. Files (in xxh_repro/, also as xxh_aliasing_repro.tar.gz) repro.c — verbatim xxHash read helpers (UB form) + memcpy reference + __may_alias__ source-fix variant; four noinline,noclone MyMap_insert_* loops compared. run.sh — builds buggy (-O2 -march=x86-64-v3) and fixed (-fno-strict-aliasing) and prints both. README.md — symptom, root cause, generated code, fixes, toolchain. Fixes (all demonstrated in the reproducer) Source (preferred): add __may_alias__ to the typedefs in XXH_read32/XXH_read64 — the may_alias-fix rows are correct even under strict aliasing. This mirrors what xxHash already does for NEON via XXH_ALIASING. Build flag: -fno-strict-aliasing (works, broader perf cost). Config: set XXH_FORCE_MEMORY_ACCESS=0 (memcpy-based reads, the documented safe path). xxh_aliasing_repro.tar.gz

Summary: Add JavaScript wrapper for OpenZL WASM Add test cases and add readme Differential Revision: D116404782