As in the fraction tail and the exponent: clang computed the digit twice,
once for the test and once for the value.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The '0' offset is linear, so it is subtracted once from i * 10^8, which is
ready early, instead of from each unit on the digit chain. Clang also
extracts both halves with one movq.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A remaining 4-7 digit run takes one SIMD step instead of the scalar loop,
as for char. The 8-digit step combines digit pairs with pmaddwd (NEON
vmulq/vpaddlq) instead of parse_eight_digits_unrolled on packed bytes,
whose three 64-bit constants made GCC 14/15 spill on the digit chain.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
GCC computed the digit twice, and the in-loop exponent saturation became a
select on the path to the power of ten. Saturate only for more than 18
exponent digits.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
If the exponent passed that test, the mantissa failed it, so it is not zero and
the exponent is within range. GCC carries this into compute_float by itself.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Clang kept from_chars_fixed_format out of line, so every conversion paid for
the call and its six register saves and restores.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The sign of the exponent, and with it whether an out-of-range value
underflows or overflows, is as unpredictable as the input. Parse the sign
without a branch, check both ends of the range with one comparison, and
select zero vs infinity and the out-of-range error without branching on
the case.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Clang generated ~35% more instructions per float than GCC on identical
code (canada.txt, 64-bit: 276 vs 200 i/f on a Xeon Gold 6548N). Two
causes, confirmed with exact instruction traces:
1. Clang declines to inline the parser (from_chars_caller<T>::call) into
its callers, so parse_options stays a runtime value and every format
flag is re-tested on every conversion: javascript, skip_white_space,
allow_leading_plus, fixed/scientific, the decimal point, the JSON
dispatch. GCC inlines the whole parser into each call site, where
chars_format::general is a constant, and all of it folds away.
Fix: from_chars dispatches chars_format::general to a
from_chars_fixed_format<T, UC, Fmt> instantiation, so the format is a
compile-time constant inside the parser body whether or not the user's
call is inlined. The call forwarder gets fastfloat_clang_really_inline
so that it folds into that instantiation.
2. Clang if-converts the rare over/underflow fix-ups at the end of
compute_float and the result_out_of_range test into cmov chains that
every conversion executes. Marking them fastfloat_clang_unlikely keeps
them as never-taken branches.
Both are applied under clang only, and GCC's generated code is identical
to before (verified on the object code). That is on purpose: forcing
always_inline on from_chars, or even on the trivial call forwarder,
regressed GCC by up to 14% on mesh.txt by changing its inlining order;
dispatching to the fixed-format instantiation made it stop inlining into
the loop; and the unlikely hints alone cost it 2-6% on mesh.txt by
reordering blocks (GCC already emits branches there).
realbenchmark, cycles per float, 5 interleaved rounds, medians:
clang 21, Xeon Gold 6548N before after
canada.txt ASCII (64) 49.7 44.6 -10%
canada.txt UTF-16 (64) 57.4 52.0 -9%
mesh.txt ASCII (64) 26.5 22.4 -16%
mesh.txt UTF-16 (64) 28.1 24.0 -15%
(32-bit: -8% to -14%)
gcc 14, same machine: generated code unchanged.
Apple clang 17, arm64: +3% to +18% Mfloat/s.
PR #356 replaced the 3/5-character case-insensitive compare used by
parse_infnan with SWAR helpers (fastfloat_strncasecmp3/5 plus a generic
memcpy-based fastfloat_strncasecmp). That code only runs for "nan",
"inf" and "infinity" inputs, so it cannot help ordinary parsing, but it
grew the inlined inf/nan tail of the parser: on x86-64 (GCC 14 and
clang 21) the per-commit benchmarks dropped by 1.5-2.5% because the
extra dead code changed inlining decisions and register allocation on
the hot path (+7 instructions/float on canada.txt).
Go back to the plain loop, which the compiler unrolls for the constant
lengths 3 and 5, and drop the now-unused generic SWAR function. The
`actual < 256` guard of the original is unnecessary: OR-ing 0x20 into
a value can only equal an ASCII lowercase letter when the value is that
letter or its uppercase form, so the plain OR is exact for every
character type.
8.3.0 added the ECMAScript leading-zero rule as a runtime test on fmt inside
parse_number_string, so unlike basic_json_fmt its error returns and Annex B
octal scan land in the parser body that every from_chars instantiation
force-inlines. from_chars_caller<double>::call grew from 935 to 1031
instructions and other formats lost about 3% on short inputs.
Make the rule a compile-time parameter of the parser body, selected once at the
entry point, and take chars_format::javascript out to a cold conversion before
anything else is live so the branch is a tail call. parse_number_string keeps
its signature and behaviour.
benchmarks/benchmark.cpp, Intel Xeon 6975P-C, clang 22.1.8, cycles per float,
best of 7:
canada.txt mesh.txt
8.2.10 47.03 24.78
8.3.0 47.34 26.08
this 46.28 24.86
chars_format::javascript follows the strict-mode grammar, which rejects
any leading zero. In sloppy mode, JavaScript also accepts a leading zero
when one of the digits is 8 or 9 ("08.5" is 8.5, Annex B's
NonOctalDecimalIntegerLiteral). A leading zero followed only by octal
digits is a LegacyOctalIntegerLiteral ("0775"), which is not a decimal
number: it is rejected with the new parse_error::legacy_octal_integer_part
so the caller can parse it in base 8.
javascript_sloppy sets one extra bit on top of javascript, and the check
lives inside the existing runtime JavaScript branch of
parse_number_string<false>, so the general path is unchanged. An
interleaved A/B with realbenchmark on canada.txt and mesh.txt (ASCII and
UTF-16, 32/64-bit) shows identical instructions per float and cycles
within noise.
Document both formats in the README.
The JSON format rejects leading zeros, which JavaScript also rejects,
but it further requires digits on both sides of the decimal point,
which JavaScript does not: ".5", "5." and "5.e3" are all valid
DecimalLiteral productions. Users lexing JavaScript therefore could not
use chars_format::json and had to re-check the integer span themselves
after a general-mode parse.
chars_format::javascript is general mode plus the leading-zero rule
(reported as leading_zeros_in_integer_part), with no_infnan. It is a
runtime check on the format, like fortran, so it reuses the existing
parse_number_string<false> instantiation. A leading minus sign is
accepted, and a leading plus sign with allow_leading_plus.
Claude-Session: https://claude.ai/code/session_01KbAWRBpE3MPy5cXECc5vWZ
Replace C-style casts with static_cast/const_cast so -Wold-style-cast
is clean, and enable that warning in the Unix test builds and the
amalgamated-header CI job.
EXP-050/052/053 were upstreamed in final form via #381 (integer-scan unroll)
and #382 (4-digit follow-up, clang-gated); the #387 span-elision restructure
then rewrote the surrounding code. This merge carries the old branch history
while the tree = upstream/main (8.2.7) + EXP-062 (ungate 4-digit SWAR on gcc)
+ EXP-063 (mantissa bound before rounds_to_nearest probe).
NOTE: EXP-052's 2x unroll of loop_parse_if_eight_digits was never upstreamed
and is dropped here pending post-#387 revalidation (see EXPERIMENTS.md).
The previous commit detects multi-wrap u64 overflow at the max_digits
boundary by re-parsing the digits through a checked multiply-add loop
(O(max_digits)). Replace that with the constant-time check used in
simdjson: the leading digit plus a single threshold comparison.
For a max_digits-length value, min_safe_u64(base) == base^(max_digits-1)
is the smallest such value and also the width of each leading-digit band
[d*ms, (d+1)*ms). Since that width is < 2^64, the only band that can
straddle 2^64 is d == dmax (the largest leading digit that still fits),
and there it straddles at most once, so a single threshold dmax*ms
separates wrapped from non-wrapped values. A leading digit above dmax
always overflows; below dmax always fits. dmax and the threshold derive
from the existing min_safe_u64 table, so no new tables are needed and
dmax*ms cannot itself overflow.
Add a programmatic, self-verifying test for parse_int_string overflow
detection covering bases 2..36, complementing the hand-picked strings
added earlier. Every generated input is cross-checked against an
independent trusted oracle (a plain 64-bit checked multiply-add); on
success the parsed value is also compared exactly and full consumption
of the input is asserted.
Per base it exercises:
- an exact-boundary sweep of the 64 values straddling 2^64
(UINT64_MAX-31 .. 2^64+31), built by walking the digit string;
- UINT64_MAX, 2^64 and the all-max-digit value, each also with
leading zeros;
- random max_digits-length values across every leading digit, with
the heaviest sampling on the lead == dmax band that straddles 2^64,
and full coverage of lead > dmax (the multi-wrap region the naive
min_safe check accepted by mistake);
- max_digits-1 (never overflows) and max_digits+1 (always overflows).
A small signed (int64_t) section checks the exact INT64_MIN/INT64_MAX
limits round-trip and that INT64_MAX+1 / INT64_MIN-1 are rejected in
every base.
