LLVM's loop unroller miscompiles sub-form reductions when introducing parallel reduction phis (llvm/llvm-project#201065): the partial accumulators are recombined with alternating signs instead of being summed. Under ThinLTO + PGO this miscompiles simdutf's arm64 utf8_length_from_latin1 in darwin-arm64/mas-arm64 release builds, undercounting UTF-8 lengths for Latin-1 strings.

On Apple Silicon this manifests as (shipped in v42.3.1):

• Buffer.byteLength() returning values 2 bytes short for one-byte strings >= 64 chars containing U+0080-U+00FF characters at affected offsets
• silently truncated Buffer.from(string) / TextEncoder.encode() results
• a heap buffer overflow followed by a CHECK crash in node::Utf8Value (e.g. fs.writeFileSync with such strings >= ~1KB)

LLVM only enables the parallel-reduction unrolling for Apple M-like CPUs (getAppleRuntimeUnrollPreferences), so only Apple targets are affected; linux-arm64 and win-arm64 target generic CPUs and cannot hit this. The flag is applied at link time, where ThinLTO backend codegen runs, and is inert on branches without macOS ThinLTO.

Validated on a local release build with the exact CI configuration (ThinLTO + Electron PGO profile): the crash and corruption repros disappear with the flag, the affected loop remains unrolled (single accumulator), and Speedometer 3.1 is unchanged (-0.84%, p=0.48, interleaved A/B).

This patch can be removed once the upstream fix (llvm/llvm-project#201066) ships in the bundled clang.

Notes: Fixed silent data truncation in Buffer/TextEncoder APIs and a crash in fs.writeFileSync with non-ASCII strings on Apple Silicon.