Add x64 baseline WebKit builds for Linux and Windows#171
Merged
dylan-conway merged 2 commits intomainfrom Mar 5, 2026
Merged
Conversation
Linux x64 was pinned to -march=nehalem for all builds in 596e48e. This splits that: default entries get -march=haswell (matching bun's non-baseline target), new -baseline entries keep -march=nehalem. Windows had no arch pin at all. Both WebKit (clang-cl) and ICU (MSVC cl.exe via MSBuild) compiled without -march / /arch:, letting the auto-vectorizer emit AVX2/AVX-512 in ICU's hash and decimal loops with no CPUID gate. Now windows-release.ps1 takes -Baseline and threads /clang:-march= into CMake flags; build-icu.ps1 injects /arch: into the .vcxproj patches (/arch:SSE2 for baseline, /arch:AVX2 otherwise). New artifacts: bun-webkit-linux-amd64-baseline{,-lto} bun-webkit-linux-amd64-musl-baseline{,-lto} bun-webkit-windows-amd64-baseline Supersedes #137.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughAdds baseline build variants across CI and release workflows for Linux, musl, and Windows. Introduces a Baseline switch and architecture flag logic in Windows scripts, updates MARCH_FLAG selection, and adjusts packaging to include baseline artifacts. Also changes mac C++ compiler default to Changes
🚥 Pre-merge checks | ✅ 1 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@build-icu.ps1`:
- Around line 117-119: The current insertion always appends a new
<AdditionalOptions> node via the $content -replace using $ArchFlag, which
duplicates /arch: values on repeated runs; modify the patch logic (the block
that checks $ArchFlag and updates $content) to be idempotent by detecting an
existing <AdditionalOptions> element and either updating any existing /arch:
token to the new $ArchFlag or replacing the whole AdditionalOptions value, and
only inserting a new <AdditionalOptions> element when none exists; ensure the
implementation targets the same pattern currently matched and preserves other
%(AdditionalOptions) entries while removing or replacing any prior /arch:
setting so rerunning the script does not accumulate multiple /arch: flags.
In `@windows-release.ps1`:
- Around line 46-52: Add a guard that fails fast when the Baseline switch is set
but the Platform is not x64: check $Baseline together with $Platform and if
$Baseline is true and $Platform is not "x64" (e.g., equals "ARM64") write an
error and exit with a non‑zero code instead of silently falling through; update
the logic around the $Platform/$Baseline decision that currently sets $MarchFlag
to ensure you validate $Baseline first (referencing the $Platform, $Baseline and
$MarchFlag variables) so misconfiguration is rejected immediately.
ℹ️ Review info
Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 6f621466-a6e0-4f75-9c05-3d153579f45a
📒 Files selected for processing (3)
.github/workflows/build-reusable.ymlbuild-icu.ps1windows-release.ps1
Comment on lines
+117
to
+119
| if ($ArchFlag) { | ||
| $content = $content -replace '(<ClCompile>)', "`$1`n <AdditionalOptions>$ArchFlag %(AdditionalOptions)</AdditionalOptions>" | ||
| } |
There was a problem hiding this comment.
Make the vcxproj arch patch idempotent.
Line [118] always inserts a new <AdditionalOptions> node. Re-running in the same output tree can accumulate conflicting /arch: values.
♻️ Proposed fix
- if ($ArchFlag) {
- $content = $content -replace '(<ClCompile>)', "`$1`n <AdditionalOptions>$ArchFlag %(AdditionalOptions)</AdditionalOptions>"
- }
+ if ($ArchFlag) {
+ if ($content -match '/arch:(SSE2|AVX2)') {
+ $content = $content -replace '/arch:(SSE2|AVX2)', $ArchFlag
+ } else {
+ $content = $content -replace '(<ClCompile>)', "`$1`n <AdditionalOptions>$ArchFlag %(AdditionalOptions)</AdditionalOptions>"
+ }
+ }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| if ($ArchFlag) { | |
| $content = $content -replace '(<ClCompile>)', "`$1`n <AdditionalOptions>$ArchFlag %(AdditionalOptions)</AdditionalOptions>" | |
| } | |
| if ($ArchFlag) { | |
| if ($content -match '/arch:(SSE2|AVX2)') { | |
| $content = $content -replace '/arch:(SSE2|AVX2)', $ArchFlag | |
| } else { | |
| $content = $content -replace '(<ClCompile>)', "`$1`n <AdditionalOptions>$ArchFlag %(AdditionalOptions)</AdditionalOptions>" | |
| } | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@build-icu.ps1` around lines 117 - 119, The current insertion always appends a
new <AdditionalOptions> node via the $content -replace using $ArchFlag, which
duplicates /arch: values on repeated runs; modify the patch logic (the block
that checks $ArchFlag and updates $content) to be idempotent by detecting an
existing <AdditionalOptions> element and either updating any existing /arch:
token to the new $ArchFlag or replacing the whole AdditionalOptions value, and
only inserting a new <AdditionalOptions> element when none exists; ensure the
implementation targets the same pattern currently matched and preserves other
%(AdditionalOptions) entries while removing or replacing any prior /arch:
setting so rerunning the script does not accumulate multiple /arch: flags.
Comment on lines
+46
to
+52
| if ($Platform -eq "ARM64") { | ||
| $MarchFlag = "/clang:-march=armv8-a+crc /clang:-mtune=ampere1" | ||
| } elseif ($Baseline) { | ||
| $MarchFlag = "/clang:-march=nehalem" | ||
| } else { | ||
| $MarchFlag = "/clang:-march=haswell" | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Fail fast when -Baseline is used on non-x64 targets.
Right now, -Baseline on ARM64 is silently ignored. A guard would prevent accidental misconfiguration.
💡 Proposed guard
$env:CC = "clang-cl"
$env:CXX = "clang-cl"
+if ($Baseline -and $Platform -ne "x64") {
+ throw "-Baseline is only supported for x64 builds."
+}
+
if ($Platform -eq "ARM64") {
$MarchFlag = "/clang:-march=armv8-a+crc /clang:-mtune=ampere1"
} elseif ($Baseline) {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| if ($Platform -eq "ARM64") { | |
| $MarchFlag = "/clang:-march=armv8-a+crc /clang:-mtune=ampere1" | |
| } elseif ($Baseline) { | |
| $MarchFlag = "/clang:-march=nehalem" | |
| } else { | |
| $MarchFlag = "/clang:-march=haswell" | |
| } | |
| $env:CC = "clang-cl" | |
| $env:CXX = "clang-cl" | |
| if ($Baseline -and $Platform -ne "x64") { | |
| throw "-Baseline is only supported for x64 builds." | |
| } | |
| if ($Platform -eq "ARM64") { | |
| $MarchFlag = "/clang:-march=armv8-a+crc /clang:-mtune=ampere1" | |
| } elseif ($Baseline) { | |
| $MarchFlag = "/clang:-march=nehalem" | |
| } else { | |
| $MarchFlag = "/clang:-march=haswell" | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@windows-release.ps1` around lines 46 - 52, Add a guard that fails fast when
the Baseline switch is set but the Platform is not x64: check $Baseline together
with $Platform and if $Baseline is true and $Platform is not "x64" (e.g., equals
"ARM64") write an error and exit with a non‑zero code instead of silently
falling through; update the logic around the $Platform/$Baseline decision that
currently sets $MarchFlag to ensure you validate $Baseline first (referencing
the $Platform, $Baseline and $MarchFlag variables) so misconfiguration is
rejected immediately.
Preview Builds
|
The C compiler was pinned (clang-21) but the C++ compiler was unqualified clang++. GH Actions macOS runner image changed between Feb 24 and Mar 3 so clang++ now resolves to Apple Clang instead of homebrew LLVM 21. Apple Clang's libc++ doesn't define _LIBCPP_AVAILABILITY_HAS_HASH_MEMORY, so LibcxxHashMemoryShim.cpp compiles to an empty object (__TEXT=0). Bun then fails to link with undefined std::__1::__hash_memory.
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
1 participant
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.
Linux x64 WebKit has been
-march=nehalemfor all builds since 596e48e. This splits it: default → haswell, new-baselineartifacts → nehalem.Windows had no
-marchat all. Both WebKit (clang-cl) and ICU (cl.exe via MSBuild) were compiling with whatever the toolchain defaulted to — recent MSVC auto-vectorizes to AVX2/AVX-512 in ICU with no CPUID gate. Nowwindows-release.ps1takes-Baselineand threads/clang:-march=into CMake;build-icu.ps1injects/arch:SSE2or/arch:AVX2into the vcxproj patches.New artifacts:
bun-webkit-linux-amd64-baseline{,-lto}bun-webkit-linux-amd64-musl-baseline{,-lto}bun-webkit-windows-amd64-baselineSupersedes #137. Related: oven-sh/bun#26071.
Note: ICU is still built with cl.exe (MSBuild). Switching to clang-cl is a follow-up.