moonbitlang / core / 6852

89%

Build Type

push

github

Committed by bobzhang

Commit Message

perf(builtin): SIMD-accelerate String::to_upper and StringView::to_upper

`to_upper` still searched with `find_by(closure)` and rebuilt the result
char by char through a `StringBuilder` on every backend, while `to_lower`
already had an allocation-free SIMD search and an exact-size copy patched
in place.

Bring `to_upper` to parity by generalising the `to_lower` helpers:

- `find_ascii_uppercase_code_unit_simd` becomes
  `find_ascii_range_code_unit_simd(data, start, len, first, last)`; the
  new `find_ascii_lowercase_code_unit` dispatcher mirrors the uppercase
  one (literal scalar loop below 24 units, else the range search).
- `ascii_lowercase_copy` becomes `ascii_case_copy(view, first_match,
  first, last, delta)`: exact-size copy, then an i16x8 patch on native
  and wasm (lane add wraps, so delta -32 subtracts 0x20) and a scalar
  in-place patch on wasm-gc.
- js keeps its `find_by` + `StringBuilder` path, now selected with
  `#cfg(target="js")` exactly like `to_lower`.

moonc never inlines functions containing loops, so the range bounds are
runtime arguments of the outlined search and copy. They only feed the
splats before the vector loop and the scalar checks; the dispatchers keep
literal short-path loops, so `to_lower`'s call structure is unchanged.
The vector-loop guards are written as `end - pos >= 8` so they cannot
overflow.

Tests: to_upper boundary tests mirroring to_lower's; a QuickCheck
differential of to_upper and to_lower against a code-unit model over
strings of 40+ units with range edges, their neighbours, non-ASCII units
with ASCII-letter low bytes and surrogates, on strings and padded views;
exhaustive position/offset sweeps; and a native/wasm whitebox test that
calls the SIMD search directly. Adds string_to_upper_bench_test.mbt
mirroring the to_lower benchmarks.

Signed-off-by: Codex CLI <codex@openai.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Coverage Stats

32 of 38 new or added lines in 1 file covered. (84.21%)

20 existing lines in 1 file now uncovered.

16550 of 18491 relevant lines covered (89.5%)

316721.05 hits per line