Use ARM64 VM image in PR/CI - #352
Merged
Merged
Conversation
Benchmark ResultsTotal benchmarks: 204 Inputs: baseline/baseline.json, bench_result.json v8 (6176ms, 4857ms) -21.4%
test-suites (317886ms, 254627ms) -19.9%
micros (60876ms, 49293ms) -19.0%
jit-benches (8563ms, 5377ms) -37.2%
many-subclasses (73437ms, 61769ms) -15.9%
map-objects (3627ms, 2796ms) -22.9%
map-strings (4335ms, 3228ms) -25.5%
nbody (3448ms, 2395ms) -30.5%
string-switch (6503ms, 4573ms) -29.7%
raytracer (5608ms, 4399ms) -21.6%
MiniReact (30332ms, 22843ms) -24.7%
widgets (12934ms, 10289ms) -20.4%
|
vmoroz
enabled auto-merge (squash)
July 27, 2026 19:35
NikoAri
approved these changes
Jul 27, 2026
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
2 participants
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
This PR moves the Windows build to Visual Studio 2026 (Clang 22 / MSVC 14.51),
switches ARM64EC from MSVC to Clang, and makes ARM64 and ARM64EC first-class
in CI: both now build the full target set and run the complete test suite on a
native ARM64 agent pool instead of being cross-compiled without tests.
ARM64 and ARM64EC had never been fully compiled (only
hermes.dll/hermes-icu.dllwere) and no test had ever run against them. Everything else inthis PR is what it took to get there.
Toolchain
build.jslocates it withvswhere -version 18; there is no VS 2022 fallback.vs2022-msvc-*CMake presets are replaced byvs2026-msvc-{x64,x86,arm64}(generator
Visual Studio 18 2026). The Ninja presets are unchanged.--msvcstill selects MSVC explicitly.correct component IDs.
ARM64EC on Clang
The MSVC force was one line; making ARM64EC actually compile and link with Clang
was the bulk of the source change. Reviewers will find one root cause behind
almost all of it:
Support/SIMD.hnowselects NEON;
VM/Profiler.hskips<x86intrin.h>/__rdtsc; llvh'sHost.cppskips the x86cpuid/xgetbvinline asm; dragonbox drops the two_umul128/_addcarry_u64fast paths; folly reportsFOLLY_SSE 0/FOLLY_NEON 1and emits an AArch64yieldforasm_volatile_pause.fiber_winfib.hppgets theBOOST_NO_EXCEPTIONSguardsfiber_fcontext.hppalready had. ARM64EC is the only target that uses winfib,and Clang hard-errors on
throw/tryunder-fno-exceptionswhere MSVC didnot.
softintrin.libis now linked for ARM64EC + Clang. MSVC emits a/DEFAULTLIB:softintrindirective automatically; Clang does not, so every linkfailed with
undefined symbol: _mm_getcsr (EC symbol)from the UCRTfloating-point objects. It is set in
CMAKE_EXE/SHARED_LINKER_FLAGSso thatCMake's configure-time
try_compilechecks link too, per-target for the.nodetest addons (MODULE libraries do not inherit those flags), and viaSHERMES_CC_SYSLDFLAGSfor the C thatshermesgenerates and links.arm64ec-pc-windows-msvctarget triple is now passed regardless of hostarchitecture, for both the main build and
shermes: on an ARM64 host Clang'sdefault target is plain ARM64, and non-EC objects cannot link against
ARM64EC output. The MSVC-only
-arm64ECflag injection is now MSVC-only.Static Hermes AOT: ARM64EC raw longjmp
lib/VM/StaticH.cppis the one non-mechanical change. Static Hermes throws viasetjmp/longjmp, and the CRT'slongjmpgoes throughRtlUnwindEx. The filealready used a raw longjmp on x64 and ARM64 to avoid unwinding across DLL
boundaries, but excluded ARM64EC — where the CRT path additionally trips
RtlUnwindEx's Control Flow Guard check(
FAST_FAIL_INVALID_LONGJUMP_TARGET,0xC0000409) whenever the AOT module isloaded into a CFG-enforced host process, which is exactly what
shermes -execdoes.
The ARM64EC
_sh_raw_longjmprestores the AArch64 callee-saved state from thex64-layout
jmp_buf(ARM64EC has no_M_ARM64ECbranch insetjmp.h, and_M_ARM64ECimplies_M_X64), following the fixed ARM64EC x64↔AArch64 registermap. The mapping, the registers that are intentionally not restored (x23/x24/x28
are never used by ARM64EC codegen) and the
MxCsrslot decision are documented inthe code. This turned 22 failing AOT lit tests into a clean run.
CI and PR pipelines
ImageOverride -equals windows-2025-1espt,which is what moves x64, x86 and all UWP cells onto the VS 2026 image.
win32_arm64andwin32_arm64ecrun on thewindows-2025-1espt-arm64pool(single-image, so no
ImageOverride) withCanRunTest: true. On a native hostboth stop being cross builds, so the tools, the unit-test binaries and the lit
drivers are built, and the C++ unit tests, JS regression tests and Test262 Intl
tests all run. The pool is selected by a per-cell
UseArm64Poolflag ratherthan by
TargetCPU, which keepsuwp_arm64on the x64 pool — UWP binaries arenot executed by the pipeline on any architecture.
and load the ARM64EC
hermes.dll/hermes-icu.dll, so the shipped artifactsare what gets exercised.
.ado/ensure-node10-shim.yml, referenced first in the ARM64 jobs. ARM64agents ship no
externals\node10, but the mandatory 1ES build-retentionpost-job still runs on the Node 10 task handler and would otherwise fail.
.ado/image/README.mddocumenting the pool ↔ image mapping. The imagedefinitions themselves are shared with
microsoft/v8-jsiand are notduplicated here.
Agent environment
The new images differ from the old ones in ways the pipeline and the build
script had silently depended on:
UseNode@1is removed. The images ship Node.js 24 onPATH; the task triedto provision a runtime instead, which the network-isolated PR pipeline blocks.
ls -R, which is not oncmd.exe'sPATHon these images. It is now a
pwshstep.build.jsis fixed. It used to take the firstgit.exeon
PATHand rewritecmdtobinin that path; on the new agents the firstGit is the agent's own bundled copy, which has no
bash.exe, so every littest failed with "Running Hermes LIT tests in CMD.exe is not supported". It
now scans all
git.exelocations plus the default install directories andpicks one that actually contains
bash.exe.Package contents
Because the ARM64 cells are now native builds, they also stage
hermes.exeandhermesc.exe. The NuGet package therefore carries tools for every targetplatform (
tools\native\release\{x64,x86,arm64,arm64ec}\) instead of only x64and x86. The existing signing patterns and nuspec globs pick them up unchanged.
Feed compliance
A repo-level
NuGet.configpins package restore to the ADO feed, and the localBinSkim download now uses that feed instead of nuget.org.
Validation
All runs are Release, on VS 2026 18.8 / MSVC 14.51.36231 / Clang 22.1.3 /
Windows SDK 10.0.28000. ARM64 and ARM64EC were validated on a native ARM64 host.
JS regression runs additionally report the pre-existing 9 expected failures and
78 unsupported tests, unchanged from
main.Machine types verified with
dumpbin /headersforhermes.dll,hermes-icu.dlland the test executables:
AA64 machine (ARM64)for arm64, and8664 machine (x64) (ARM64X)for arm64ec.Notes for reviewers
vs2022-msvc-*presets are gone.substantially longer than the previous library-only cross builds.
additive
__arm64ec__guards to minimize friction when syncing upstream.