Open
Conversation
Collaborator
|
Review requested:
|
Renegade334
previously requested changes
Feb 15, 2026
Member
There was a problem hiding this comment.
This needs the unicode.h aspects of v8/v8@ee2873a to unblock gcc builds.
9acf475 to
eb0d45c
Compare
eb0d45c to
a215fe8
Compare
Original commit message:
Reland "use highway to check and copy leading ascii"
This is a reland of commit a3e84e5f01540cec142f4d4f41f1921373c220e5
Original change's description:
> use highway to check and copy leading ascii
>
> Change-Id: I065532aeeee95273821aa1f25b5ffc5c5c23cbf1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7172479
> Reviewed-by: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Dan Carney <dcarney@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#103820}
Change-Id: I43b4ad18817eb52b701e112d2d0a5f685374ae1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7184338
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Dan Carney <dcarney@chromium.org>
Cr-Commit-Position: refs/heads/main@{#103865}
Refs: v8/v8@67507b2
a215fe8 to
883bf5e
Compare
Original commit message:
Fix GCC Build
Move explicit specializations of Utf8::IsAsciiOneByteString to namespace
scope
C++ forbids explicit template specializations inside class scope.
The specializations for IsAsciiOneByteString<uint8_t> and
IsAsciiOneByteString<uint16_t> were defined inside class unibrow::Utf8,
riggering "explicit specialization in non-namespace scope"
compile errors.
Fix type mismatch in EXPECT_EQ comparisons for std::pair values
The tests failed because EXPECT_EQ was comparing pairs with mismatched
template parameters — std::pair<int, unsigned int> vs.
std::pair<unsigned int, unsigned char> — which have no valid operator==.
I corrected the expected values to use the same unsigned types as the
actual data, ensuring the pair comparison compiles cleanly.
Fix build failure on GCC 12 by replacing std::format with ostringstream
GCC 12's libstdc++ does not implement <format>, causing compile errors
when using std::format. Replaced all std::format calls with equivalent
Change-Id: I5c31f91065eccf6f4c14172902ffcd99863ebbb9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7138905
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#104280}
Refs: v8/v8@ee2873a
883bf5e to
ad11612
Compare
Contributor
Author
|
I decide to keep only one backport on this PR and the Fix GCC Build (ee2873a6303d). I will open another PR once this is merged with the backport for https://chromium-review.googlesource.com/c/v8/v8/+/7159233 |
Renegade334
reviewed
Feb 17, 2026
Member
Renegade334
left a comment
There was a problem hiding this comment.
I believe this violates the commit-rebase policy, as each individual commit needs to (in principle) independently pass CI, which isn't the case here. I would just edit the backport commit to include the small change to the header, don't know what you reckon @targos?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Cherry-picks two V8 commits to add Highway-based
WriteLeadingAsciiand fix its GCC build:67507b2a88f4— Reland "use highway to check and copy leading ascii" (Dan Carney)Replaces
IsAsciiOneByteString+memcpywith HighwayWriteLeadingAsciiinUtf8::Encode, providing a faster ASCII fast path forWriteUtf8V2.CL: https://chromium-review.googlesource.com/c/v8/v8/+/7184338
ee2873a6303d— Fix GCC Build (Abdirahim Musse)Moves
WriteLeadingAsciiexplicit template specializations to namespace scope — C++ forbids them inside class scope, and GCC rejects it.CL: https://chromium-review.googlesource.com/c/v8/v8/+/7138905
Note: only the
unicode.hportion of this commit is included; the test file changes (heap-unittest.cc,module-decoder-unittest.cc) do not apply cleanly to Node.js's V8 copy and are unrelated to theWriteLeadingAsciifix.This patch addresses part of the remaining ~30-40% performance gap in
WriteUtf8V2vs v22 after #61712 landed the initialsimdutf+memcpyfast path.Refs: #60719
Test plan