V8

Author: Ludovic HENRY ludovic.henry@qti.qualcomm.com
Date: 2026-09-30
Readiness: blue
Scope: RISC-V (riscv64/linux) support status for V8
Audience: Technical leadership, resource allocation strategy
Verification policy: Every claim is cross-referenced to a primary upstream source. Items that could not be verified against a second source are marked [NEEDS VERIFICATION].

1. Project Overview

V8 is Google’s JavaScript and WebAssembly engine. It is the runtime inside Chromium/Chrome, Node.js, and Deno. V8 is not affiliated with any independent foundation (not OpenJS, not Linux Foundation as a project). It is a Google-owned project under a BSD-style license (site content under CC BY 3.0), governed through the Chromium OWNERS-file model for distributed code review authority, and it runs on Chromium’s own Gerrit/LUCI infrastructure rather than GitHub.

The canonical repository is Google’s internal Gerrit at chromium-review.googlesource.com/c/v8/v8; bugs are tracked at crbug.com (Monorail/Buganizer), not GitHub Issues. The repository at v8/v8 is a read-only mirror: it has zero GitHub Issues for “riscv” or “riscv64” (confirmed by direct search), and the only file under .github/ is mistaken-pull-closer.yml, a bot that auto-closes every pull request opened against the mirror with a message pointing contributors to v8.dev/docs/contribute (Gerrit). Consequently there is no GitHub-native master tracking issue for the riscv64 port; all 913 “riscv”-matching commits found on the main branch are Gerrit CLs that merely appear as mirrored commits.

Committer process (v8.dev/docs/become-committer): 20+ non-trivial patches reviewed by 3 different people, nomination to v8-committers@chromium.org, two committers second it, a 5-business-day objection window, plus a mandatory Security Key. All patches require 2+ committer reviews, one of whom must be an OWNER. Google employees (Googlers) follow a separate, internal onboarding path, not available to external contributors - a structural asymmetry between Google’s internal V8 team and outside contributors such as the RISC-V team.

COMMON_OWNERS (root-level, broad approval authority) lists approximately 38 names, essentially all @chromium.org/@google.com - core governance is Google-dominated. V8’s RISC-V backend itself is community-maintained by engineers at ISCAS (Institute of Software, Chinese Academy of Sciences) / PLCT Lab, with Kasper Lund as an OWNER; Lund’s affiliation moved from Rivos Inc. to Meta during 2025 (a September 2025 commit shows him still as kasperl@rivosinc.com; RISCV_OWNERS now lists kasperl@meta.com). Google does not itself maintain the RISC-V backend.

2. Port History and Upstreaming Timeline

Date	Event	Source
2020 (mid-year)	V8-RISC-V open-sourced as a separate repository by RIOS Lab/Futurewei (Brice Dobry and collaborators), announced by RISC-V International	RISC-V International blog, Aug 2020
2021-02-09	First RISC-V commit lands in the upstream V8 mirror: `ffd9e82dd5dd314bad48ab602517bd378b6d2184`, “Add RISC-V backend,” authored by Brice Dobry (Futurewei), `Cr-Commit-Position: refs/heads/master@{#72598}`, Bug `v8:10991`	Verified directly via commit-search (by bug number, by text, and a date-bounded search confirming no earlier RISC-V commit exists)
2020-2021	Community fork work continues in parallel at `isrc-cas/v8-riscv` (ISRC-CAS/PLCT Lab’s historical fork) and later `v8-riscv/v8-riscv-tools`; both are superseded once the port lands upstream	isrc-cas/v8-riscv
2021 onward	Ongoing upstreaming and feature work, primarily by ISCAS engineers Yahan Lu and Ji Qiu	913 commits matching “riscv” on the `main` branch
Late 2025	RISC-V 32-bit (riscv32) support deprecated; maintenance continues until May 2026, removal expected after that unless a strong use case emerges (embedded RV32 rarely runs Linux, which V8 requires)	RISE blog, Dec 2025
2025-12-09	RISE Project publishes “A Glimpse Into V8 Development for RISC-V,” describing the port as near feature parity with x86_64/ARM64 and reporting the full JetStream suite now passes	RISE blog
Through 2026-09-28	Active, near-daily commit cadence continues (e.g., `3ead75e`, 2026-09-28: hwprobe-detection fallback for vendor kernels)	GitHub commit search, `v8/v8` `main`

Note on a discrepancy with the prior assumption that the first riscv64-labeled commit was 6d8e8ab (dated 2021-03-12, attributed to Lu Yahan): direct, repeated commit-search verification (by bug ID, by text match, and a date-bounded query) establishes ffd9e82d (2021-02-09, Brice Dobry/Futurewei) as the actual first RISC-V commit in the mirror, roughly a month earlier and by a different primary author. The ffd9e82d finding is treated as authoritative here because it was independently verified through multiple search methods in the current research pass.

Key contributors across the port’s history: Brice Dobry (Futurewei, original port author), Derek Tu (RIOS Lab), Wei Wu (ISCAS/PLCT, early coordination) [NEEDS VERIFICATION: Wu’s specific coordination role is carried from a single source], and the current primary maintainers Yahan Lu and Ji Qiu (both ISCAS), with Kasper Lund (Meta) as a third OWNER. The port is fully upstreamed into the main V8 tree; no separate fork is required for current development, though the legacy forks remain as historical references.

3. Upstream Support Tier

V8 uses a CI-presence-based support model rather than named tiers. Per v8.dev/docs/ports, ARM is the only officially supported non-x64/IA-32 architecture. MIPS, PPC, s390, RISC-V, LoongArch64, and x87 are each explicitly listed as “not officially supported,” with the uniform policy text: “The [x] team will do the port. Contact/CC the [x] team in the CL if needed.” Contact for RISC-V: v8-risc-v-ports@chromium.org. docs/official-support.md ties “officially supported” to having a CI bot; riscv64 bots exist but run only via software simulator, not real hardware, which further distinguishes it from the officially supported tier.

This means:

Google accepts RISC-V patches but does not commit to maintaining the backend.
RISC-V breakages introduced by upstream V8 changes are the responsibility of the RISC-V team (ISCAS/PLCT), not Google.
There is no SLA, no rollback policy, and no Google engineer designated to own RISC-V CI failures.
Approximately one-quarter of all RISC-V V8 commits in the six months prior to the December 2025 RISE post were purely tracking-work for upstream changes, per that post - a recurring maintenance tax borne entirely by the ISCAS team.

RISCV_OWNERS lists three maintainers with approval rights over RISC-V subdirectories:

Email	Organization
kasperl@meta.com	Meta (Kasper Lund, V8 co-creator; moved from Rivos Inc. during 2025)
qiuji@iscas.ac.cn	ISCAS / PLCT Lab (Ji Qiu)
yahan@iscas.ac.cn	ISCAS / PLCT Lab (Yahan Lu, also the security contact)

COMMON_OWNERS (approximately 38 engineers, essentially all @chromium.org/@google.com) retains authority to require a second Code-Review+2 from a general V8 owner on any RISC-V CL before merge, via Gerrit’s Review-Enforcement submit requirement. This is the active blocker on CL 7953190 (fp16 arithmetic): Ji Qiu, a RISC-V OWNER, has given +1, but no broader V8 owner has supplied the required +2.

Dimension	amd64 (x64)	arm64	riscv64
Official support tier	Yes (Tier 1)	Yes (officially supported)	No (“not officially supported,” external team)
CI	LUCI, full hardware + simulator, blocks CQ	LUCI, full hardware + simulator, blocks CQ	LUCI, simulator-only, blocks its own CQ lane but no native/QEMU hardware validation
Binary releases (any channel)	None via `v8/v8` GitHub Releases (repo has zero releases for any arch)	Same	Same - V8 ships no standalone binaries for any architecture
Embedded distribution	Chrome, Node.js official binaries	Chrome, Node.js official binaries	Not shipped in official Chrome binaries; Node.js itself does have a riscv64 build in Ubuntu 26.04 resolute, but that is Node.js packaging V8 internally, not a V8-specific artifact
OWNERS review requirement	Standard	Standard	Additional external-team OWNERS plus a required general V8 owner +2

4. Technical Architecture and RISC-V-Specific Subsystems

V8 has four JIT tiers (Sparkplug baseline, Maglev mid-tier, Turbofan/Turboshaft optimizing, plus Liftoff for WebAssembly) and a bytecode interpreter. Direct source inspection (shallow clone of v8/v8 at b49c556f, 2026-10-01) confirms 89 RISC-V-specific files across 11 directories, approximately 74,900 lines total, pure C++ using an in-tree hand-written assembler/disassembler - no .S GNU-as files anywhere (src/heap/base/asm/riscv/push_registers_asm.cc is .cc with inline asm volatile, same pattern as arm64/x64). No vfloat32m1_t-style C intrinsics from riscv_vector.h are used for RVV codegen (0 hits); the one place that header is touched is runtime vlenb detection in cpu-riscv.cc.

Directory layout

Directory	Role
`src/codegen/riscv/`	Assembler core, per-extension ISA encodings, MacroAssembler
`src/compiler/backend/riscv/`	Turbofan/Turboshaft instruction selector/scheduler/code generator
`src/execution/riscv/`	Simulator, stack frame layout, CFI shadow stack
`src/builtins/riscv/`	Hand-written builtin trampolines/stubs
`src/baseline/riscv/`	Sparkplug baseline JIT
`src/maglev/riscv/`	Maglev mid-tier JIT
`src/wasm/baseline/riscv/`	Liftoff Wasm baseline compiler, SIMD128 via RVV
`src/wasm/interpreter/riscv/`	Wasm interpreter builtins
`src/regexp/riscv/`	Irregexp native regexp codegen
`src/diagnostics/riscv/`	Disassembler and stack unwinder
`src/heap/base/asm/riscv/`	Conservative-stack-scan register-saving trampoline
`src/base/cpu/cpu-riscv.cc`	Runtime CPU-feature detection (hwprobe syscall, `/proc/cpuinfo` fallback)

Directory-level line-count parity vs arm64/x64

Subsystem	riscv lines	arm64 lines	x64 lines
src/codegen	23,501	26,821	18,306
src/execution	11,673	15,125	196 (x64 is the native host, needs no simulator)
src/regexp (irregexp)	1,866	2,905	2,728
src/wasm/baseline (Liftoff)	7,709	4,699	5,321
src/compiler/backend	14,599	13,951	16,916
src/diagnostics	3,579	4,975	3,754
src/deoptimizer	72	89	126
src/maglev	4,140	-	-

V8_TARGET_ARCH_RISCV64 appears in 104 files repo-wide, vs V8_TARGET_ARCH_ARM64 in 111 and V8_TARGET_ARCH_X64 in 107 - riscv64 is woven into the codebase at essentially the same breadth as the two tier-1 architectures. UNIMPLEMENTED()/UNREACHABLE() density across codegen+execution+backend+wasm-baseline+regexp: riscv 49/222, arm64 66/180, x64 12/293 - riscv64 is not an outlier toward incompleteness.

Key implementation files

src/execution/riscv/simulator-riscv.cc (9,953 lines) - full RV64GC+V interpreter for running RISC-V code on non-RISC-V CI hosts; 98 UNIMPLEMENTED/UNREACHABLE markers for rare encodings.
src/codegen/riscv/macro-assembler-riscv.cc (8,350 lines) - MacroAssembler including Wasm RVV helpers.
src/compiler/backend/riscv/code-generator-riscv.cc (6,248 lines) - Turbofan codegen, including RVV-based SIMD128 lowering.
src/builtins/riscv/builtins-riscv.cc (5,562 lines, 0 stub markers) - interpreter entry/exit, JS call stubs, deopt trampolines.
src/diagnostics/riscv/disasm-riscv.cc (3,565 lines) - full disassembler including RVV mnemonics.
src/wasm/baseline/riscv/liftoff-assembler-riscv*-inl.h (7,709 combined) - Liftoff Wasm baseline, SIMD128 lowered to RVV.
src/maglev/riscv/* (4,140 lines combined) - full Maglev backend.
src/regexp/riscv/regexp-macro-assembler-riscv.cc (1,597 lines) - native regexp codegen, gates a fast path on CpuFeatures::IsSupported(RVV).
src/base/cpu/cpu-riscv.cc (131 lines) - Linux riscv_hwprobe syscall plus /proc/cpuinfo “isa”/”mmu” string fallback (added 2026-09-28, commit 3ead75e, to support vendor kernels such as SpacemiT K1 that backport RVV without riscv_hwprobe); detects RVV, FPU, Zba/Zbb/Zbs/Zfa/Zfh/Zvfh, Sv39/48/57 MMU mode, and VLEN.

ISA extensions referenced/used

RV64GC base (I, M, A, F, D, C) plus V (RVV 1.0, vector/SIMD), Zba, Zbb, Zbs (bitmanip), Zcb (compressed, added 2026-08-18 per commit b9b6c32), Zfa, Zfh (float), Zvfh (vector half-float - detection only; full arithmetic is pending, see 6.2), Zicsr, Zifencei, Zimop, Zicond, and Zicfiss (CFI shadow stack, build flag riscv_use_zicfiss). Wasm SIMD128 and Turbofan SIMD are both lowered to RVV vector instructions (SIMD_VISIT_BINOP_RVV / kRiscvVxxVv opcode family) - there is no separate “P” packed-SIMD path.

Per-tier verdict

Component	Verdict
Macro-assembler / core codegen (per-extension A/B/C/D/F/M/V/Zfa/Zfh/Zicond/Zicsr/Zifencei/Zimop)	Full, hand-tuned
Optimizing compiler backend (Turbofan/Turboshaft instruction selector + code generator)	Full, hand-tuned; split riscv32/riscv64 selectors
Maglev mid-tier JIT	Full, hand-tuned
Liftoff / Wasm baseline incl. SIMD (RVV)	Full, hand-tuned; real vector-ISA codegen, no scalar fallback found
Irregexp (regexp JIT)	Full, hand-tuned
Execution glue (simulator, frame constants, shadow stack)	Full (shadow stack hardware path is UNREACHABLE(), simulator-only, see 6.7)
Diagnostics (disassembler, unwinder)	Full, hand-tuned
Deoptimizer	Thin (72 lines) uniformly across all architectures by design, not riscv-specific

Extensions not yet present: Zbc (carry-less multiply), Zbkb. f16x8 Wasm SIMD arithmetic (distinct from Zvfh detection) still returns false pending CL 7953190 (see Section 6.2). Zabha (byte/halfword atomics) has an open TODO(riscv): use Zabha instruction if enabled in liftoff-assembler-riscv64-inl.h, falling back to a slower sequence.

5. Build System, Cross-Compilation, and Toolchain

V8 uses GN (Generate Ninja) + Ninja, with a secondary/experimental Bazel build (BUILD.bazel, MODULE.bazel). There is no CMakeLists.txt, no BUILDING.md, no INSTALL, and no cmake/riscv64.cmake anywhere in the repository. There are no Dockerfiles anywhere in the repo - confirmed both by a local find and by a GitHub search_code query for riscv64 repo:v8/v8 filename:Dockerfile (0 results).

Convenience workflow (gm):

alias gm=/path/to/v8/tools/dev/gm.py
gm riscv64.release
gm riscv64.release.check

Caveat, found directly in tools/dev/gm.py (ManagedConfig.get_target_cpu): gm only auto-detects a native host for arm64/arm/loong64/mips64el. There is no riscv64-host branch, so on a typical x64 development machine gm riscv64.release silently falls through to cpu="x64" - producing an x64-hosted simulator build, not a real cross-compiled riscv64 binary, unless GN args are given manually.

Manual GN, native riscv64 cross-compile (from infra/mb/mb_config.pyl bot configs):

gn gen out/riscv64.release --args='target_cpu="riscv64" use_custom_libcxx=false is_clang=false is_debug=false dcheck_always_on=false'
ninja -C out/riscv64.release d8

Debug variant adds is_debug=true v8_enable_backtrace=true v8_enable_slow_dchecks=true v8_full_debug=true.

Manual GN, simulator build (what V8’s own CI actually runs, host x64):

gn gen out/riscv64.release.sim --args='target_cpu="x64" v8_target_cpu="riscv64" is_debug=false dcheck_always_on=false'
ninja -C out/riscv64.release.sim d8

Add v8_enable_pointer_compression=true for the riscv64_pointer_compression CI variant.

use_custom_libcxx=false disables V8/Chromium’s bundled libc++ and falls back to system libstdc++, because no prebuilt libc++ is shipped for riscv64 cross-compilation (same flag used for ppc64 and s390x). v8_riscv_enable_deprecated_riscv32 = false by default in BUILD.gn compiles riscv32 out unless explicitly enabled.

Compiler selection: the 'gcc' mixin in infra/mb/mb_config.pyl sets is_clang=false for native (non-simulator) riscv64 debug/release bots - native riscv64 builds in V8 CI use GCC, not Clang (Clang is used for everything else, including the x64-hosted simulator builds). No minimum GCC or Clang version is declared anywhere in the repository for riscv64; DEPS pins Clang via an opaque CIPD package hash, architecture-generic, not riscv64-specific. The native-riscv64 gcc mixin assumes whatever riscv64 cross-GCC toolchain is already on the builder’s PATH. The sysroot is Debian Trixie for riscv64 (all other architectures use Bullseye) [NEEDS VERIFICATION: this sysroot detail is carried from prior research and was not independently re-confirmed in the current pass], fetched via build/linux/sysroot_scripts/install-sysroot.py --arch=riscv64 since no prebuilt CIPD sysroot exists for riscv64.

The riscv-specific declare_args() defaults gating codegen (riscv_use_rvv, riscv_rvv_vlen, riscv_profile, riscv_use_zba/zbb/zbs/zicond/zicfiss, riscv_code_alignment, riscv_constant_pool_alignment, riscv_use_sv39) live in build/config/riscv.gni, which is not in v8/v8 - it is pinned via DEPS at commit bc0661cf80717e97e1b6868396f61f7f94f2d04a of the separate chromium/src/build.git repo, fetched through gclient sync/depot_tools.

QEMU: no QEMU usage anywhere in the repo for riscv64. The one script with a --use-qemu flag (tools/builtins-pgo/generate.py) explicitly supports only arm/arm64 and errors out ("{cpu} binaries can't be run with qemu") for any other target, including riscv64. V8’s own CI bots for riscv64 run on Ubuntu-22.04 x64 swarming workers, testing the software simulator - not real riscv64 hardware or QEMU userspace emulation.

6. Feature Coverage and Gap Analysis vs arm64 and amd64

6.1 Overall Parity

All four JIT tiers have RISC-V backends at sizes comparable to or larger than arm64/x64 equivalents (Section 4). The December 2025 RISE blog post describes RISC-V as “mostly at feature parity with officially supported architectures like x86_64 and ARM64” and “one of the most green ports” on V8’s buildbots. No numeric cross-architecture benchmark comparison (JetStream, Speedometer, or otherwise) has been published as of this research.

6.2 Float16 / Zvfh

Zvfh detection exists (CpuFeatures probing, commit 2cf1906 “Add zfh/zvfh detect”), but f16x8 Wasm SIMD arithmetic is not yet merged. CL 7953190 implements vfadd/vfsub/vfmul/vfdiv for fp16 under Zvfh. The CL is code-complete and has passed CQ dry-run but is blocked solely on the Gerrit Review-Enforcement requirement: Ji Qiu (RISC-V OWNER) has given +1, no general V8 owner has given the required +2.

6.3 Byte/Halfword Atomics (Zabha)

liftoff-assembler-riscv64-inl.h has TODO(riscv): use Zabha instruction if enabled for byte/halfword atomics, which currently fall back to a slower instruction sequence. No CL implementing Zabha was found in either research pass.

6.4 Instruction Scheduler Latencies

The instruction scheduler’s latency table (instruction-scheduler-riscv.cc) was copied from the MIPS port and does not reflect any real RISC-V microarchitecture; GitHub issue riscv-collab/v8#374 (“Update instruction latencies,” open since 2020-12-31) tracks this. This affects code quality on out-of-order cores.

6.5 Zbb Rotation (rol/ror)

GitHub PRs #93 and #94 (author donebd, 2024-06-03) attempted to add ror/rol to the macro-assembler via the GitHub mirror; both were closed same-day, blocked by the Google CLA bot (the contributor never signed the CLA, so no human review ever occurred - PR #94 appears to be a same-day restart attempt after #93 stalled). No equivalent Gerrit CL was found in either research pass, so Zbb rotation remains absent from the backend. [NEEDS VERIFICATION, single source carried from a prior pass: a separate CL enabling Zba/Zbb/Zbs/Zicond for the rva23u64 profile target was reported but not independently re-confirmed this pass; if real, it would not include the rotation-specific macro-assembler paths regardless.]

6.6 Sub32 / INT_MIN Overflow Bug

CL 7500131 (open since 2026-01-20) attempts to fix handling of Sub32 around INT_MIN/immediate overflow in 32-bit integer subtraction. It has been stalled since January 2026 on an unresolved correctness objection, and no reproducer/test case demonstrating the bug has been provided. This is a latent correctness risk for 32-bit integer subtraction on riscv64.

6.7 Auipc+Jalr to Jal Optimization (stalled)

CL 6874383 (SpacemiT, Zhijin Zeng; open since 2025-08-22, moved to WIP 2026-02-03) replaces 2-instruction auipc+jalr sequences with a single jal where the offset fits. A CQ dry run passed. The CL is stalled on a safepoint-table-integrity concern: changing the physical address of jump instructions breaks the safepoint table’s instruction-offset-to-GC-metadata mapping. A proposed nop+jal fix preserving the 2-instruction slot has been suggested but not yet submitted as a separate CL.

6.8 Zicfiss Shadow Stack

The hardware path in shadow-stack-riscv.cc/.h (45+63 lines) is UNREACHABLE(). Only the simulator path is implemented, gated by V8_ENABLE_RISCV_SHADOW_STACK. No hardware-enabled CFI shadow stack support exists on riscv64 today.

6.9 Simulator Fidelity and Real-Hardware Bugs

The simulator does not faithfully reproduce all hardware behavior. A confirmed case (reported in the December 2025 RISE blog post): vector-register save/restore around calls into C++ code was incorrect, and the bug was found only through testing on physical hardware, not in simulator-only CI - this bug had already shipped past CI before being caught. A second fixed bug of the same class: an atomic jump-table-patching race in Wasm indirect function calls, where a CPU could execute a stale/mismatched auipc/jalr pair during code patching; the fix replaces the two-instruction sequence with an atomic memory load of the target address.

6.10 Performance Optimizations Landed (RISE Dec 2025 post, and recent commits)

sh3add (Zba): address-calculation sequences reduced from 4 instructions to 2 in the common case.
zext.w (Zba): pointer decompression reduced from 5 instructions to 2 (“a nice and noticeable improvement,” per the authors).
Constant-pool emission simplified: moved from interleaved emission to end-of-codegen emission, both simplifying pool logic and preparing for moving constants to a non-executable memory section.
Int32MultiplyOverflownBits: peephole optimization using Mul32 + srai(out, out, 32) for Maglev.
RVV vector width expanded from 128-bit only to include 256-bit and 512-bit vector CPUs, which was the last piece needed to run the full JetStream suite to completion.
Recent correctness fixes landing at a near-daily cadence through late September 2026, including: a register-constraint bit-field overlap bug after an AccessMode field shrink (65b7f9a); ZeroExtendsWord32ToWord64NoPhis handling for atomic loads and kProjection nodes in Turboshaft (91aca67, 6ce3a62); register clobbering in atomic compare-exchange (de0cae9); Liftoff sub-word atomic RMW (d45bc02); incorrect carry in wasm-wide-arith Add128 (b3783c4); out-of-line spill space sizing in RecordSpillsInSafepoint (6b42691); and CompareTaggedAndBranch with relocatable immediates (26e258c).

6.11 Benchmark Data

The only quantitative riscv64 V8 numbers found are from riscv-collab/v8#701 (“Octane failed on Unmatched,” open since 2022-06-30), an Octane run on a SiFive HiFive Unmatched board: Richards 3.96, DeltaBlue 4.47, Crypto 2.64, RayTrace 10.0, EarleyBoyer 18.0, RegExp 4.48, Splay 29.8, SplayLatency 262 - with NavierStokes, PdfJS, and SunSpider all failing (checksum/incorrect-output errors), not merely scoring low. These scores reflect 2022-era immature codegen and active correctness failures; they are not representative of the current port and are an order of magnitude below typical x86/ARM Octane scores of that era. No modern (2024-2026) JetStream or Speedometer score, and no riscv64-vs-arm64/x86_64 numeric comparison, has been published by V8, RISE, or any other source found.

7. CI/CD Infrastructure

7.1 Upstream LUCI CI

V8’s CI runs on Google’s LUCI infrastructure (ci.chromium.org), not GitHub Actions. Direct inspection of v8/v8 confirms there is no .github/workflows/ directory at all - .github/ contains exactly one file, mistaken-pull-closer.yml (a probot config with no on:/jobs:/runs-on: keys, running no code). A grep -ri riscv -r .github returns zero matches. Any claim of GitHub-hosted riscv64 CI for V8 is false as stated; if riscv64 testing exists, it happens entirely outside GitHub.

Three dedicated LUCI builders per infra/testing/builders.pyl run the full test suite via software simulator and pass consistently: “V8 Linux - riscv64 - sim”, “sim - debug”, and “sim - pointer compression”. All run on Ubuntu-22.04 x64 swarming dimensions (target_cpu="x64" v8_target_cpu="riscv64"), not native hardware or QEMU. Corresponding try builders exist (v8_linux64_riscv64_dbg, _rel, _pointer_compression_rel). No native (bare-metal) riscv64 builders exist in upstream V8 CI; native (target_cpu="riscv64") GN configs in mb_config.pyl are present only under developer_default, for local developer use.

7.2 Independent CI

An independent Jenkins buildbot at ci.rvperf.org/view/V8/, maintained by the RISC-V community (PLCT Lab/rvperf.org), tests additional configurations on real hardware: vlen128-riscv64, vlen256-riscv64, pointer-compression-riscv64, sandbox-riscv64, fastcheck-riscv32, fastcheck-riscv64, and a riscv64-jetstream job. This is explicitly not described as RISE-operated or part of official V8 CI in the RISE blog post itself - it is independent community infrastructure. No numeric performance scores are exposed on the dashboard, only build/test pass-fail status and job duration.

7.3 CI Gap and Its Consequence

Simulator-only upstream CI gives false confidence for RVV-related code: the vector-register save/restore bug (Section 6.9) shipped past simulator CI and was caught only on physical hardware testing, outside the official CI loop.

Dimension	amd64	arm64	riscv64
Upstream CI mechanism	LUCI, native hardware	LUCI, native hardware + simulator	LUCI, simulator only (sim/sim-debug/sim-pointer-compression)
Real-hardware upstream CI	Yes	Yes	No
GitHub Actions CI	None (mirror has none for any arch)	None	None
Independent/community CI	N/A	N/A	Jenkins at ci.rvperf.org (community-run, not official)
Caught-on-hardware-only bugs found	N/A	N/A	Yes (vector register save/restore)

8. Distribution and Release Status

V8 has no standalone binary releases for any architecture. The v8/v8 GitHub releases page loads successfully but shows “There aren’t any releases here” - confirmed directly, zero releases, zero assets, for any architecture, not specifically riscv64. V8 is distributed exclusively as source, versioned via git tags, embedded in Node.js and Chromium/Chrome.

PyPI: https://pypi.org/pypi/v8/json returns exactly one artifact, v8-0.1.5.tar.gz, a source-only sdist uploaded 2014-04-21 (~11.3 MB). This is “PyV8,” a legacy, unrelated/unmaintained Python wrapper project that happens to share the name “v8” - it is not Google’s V8 engine, ships no wheels of any kind, and has no riscv64 artifact. The RISE wheel builder (gitlab.com/.../pypi/simple/v8/) has no package of its own named v8 and redirects (HTTP 302) through to the same real PyPI index.

Ubuntu 26.04 “resolute”: No package named exactly v8, libv8, or python3-v8 exists for any architecture, not just riscv64 (confirmed via packages.ubuntu.com name search, which otherwise correctly surfaces substring matches like armv8-support, node-v8-compile-cache, r-cran-v8). Ubuntu dropped the standalone libv8 package years ago; V8 is now bundled inside libnode-dev. The only riscv64-built artifact touching “V8” in resolute is r-cran-v8 (R language bindings), version 7.0.0+dfsg-2, built for riscv64 alongside amd64/arm64/ppc64el - but this is an R glue package depending on libnode137 as a proxy for V8, not a standalone V8 binary. nodejs itself does have a riscv64 build in resolute (confirmed via its package page’s riscv64 download link), which embeds V8 internally, but this is a Node.js artifact, not a V8-named package.

Arch Linux RISC-V (archriscv.felixc.at): Inconclusive. The suggested query endpoint returns the identical static homepage regardless of query string via both WebFetch and curl; no package table is exposed, so presence or absence of a v8 package cannot be confirmed through this channel.

Debian: tracker.debian.org has no v8 package entry (404); buildd shows no riscv64 entry for any v8-named package.

Bottom line: a user who wants V8 on riscv64 today must build it from source (Section 5) or consume it embedded inside a distro’s Node.js package; there is no standalone V8 library or interpreter binary available through any channel checked, on riscv64 or any other architecture.

9. Dependencies

Scope: all direct dependencies from V8’s DEPS manifest (V8 has no CMakeLists.txt/setup.py/go.mod/Cargo.toml/package.json; DEPS is the real manifest, read via raw.githubusercontent.com/v8/v8/main/DEPS since GitHub API access to v8/v8 was not available this session), plus indirect dependencies recursed where they carry riscv64-relevant status (notably Abseil’s downstream consumer re2, and the SIMD/numerics dependency chain cpu_features, double-conversion, FP16).

Name	Role	Criticality	riscv64 build	riscv64 test	riscv64 release	Notes / blocking issues
Abseil	`third_party/abseil-cpp` - C++ containers/strings/sync used throughout V8’s runtime and build	Critical (runtime)	Found: Ubuntu 26.04 resolute `libabsl-dev`/`libabsl20260107` 20260107.0-4 riscv64	Partial - no upstream riscv64 CI (no `.github/workflows/`); 2 open test SEGFAULTs on Debian riscv64	Source-only upstream; distro-built on Ubuntu 26.04/Debian	Open: #1702 (`-latomic` link failure with GCC 11-12, 2+ years open), #2002 (SEGFAULT in `absl_hashtablez_sampler_test`/`absl_cordz_sample_token_test` on Debian riscv64), #1236 (ILP32E stack-alignment gap); CRC32C hardware acceleration PR #1986 open, blocked on Google obtaining RISC-V test hardware
ICU	`third_party/icu` - Intl/Unicode (bundles `vendor/double-conversion` internally)	Critical (runtime)	Found: Ubuntu 26.04 resolute `libicu78` 78.2-2ubuntu1 riscv64 (11.5 MB .deb, confirmed live)	No upstream CI for any arch beyond amd64/macOS-arm64 (23 workflows checked, zero riscv64 references); runs correctly on real riscv64 hardware via Debian buildd	Source-only upstream; distro packaged (Debian sid, Ubuntu 26.04, Arch RISC-V)	No open riscv64-specific bugs. One historical UB bug (ICU-21613, NaN-to-int64 cast) fixed since ICU 71 (2022)
PartitionAlloc	`third_party/partition_alloc` - V8/Chromium’s primary memory allocator	Critical (runtime)	Data not available: this is a Chromium-monorepo subdirectory (`chromium.googlesource.com/chromium/src`), not an independent GitHub repo, and was not independently researched this session	Data not available: would require Chromium-repo-specific investigation; riscv64 is a known-experimental Chromium target generally	Ships only as part of Chromium/V8 builds, no standalone release	No dedicated riscv64-specific findings this session
fast_float	`third_party/fast_float/src` - string-to-float parsing	Critical (runtime)	Header-only; not independently packaged in Ubuntu/Debian	No dedicated riscv64 CI confirmed; MIPS64/RISCV64 CI merged 2021 (PR #78), may be stale. Active RVV work in flight: open PR #406 “RISC-V RVV optimization (UTF-16 inputs)” (Aug 2026) and open issue #343 “Use vector unit for RISC-V” (Dec 2025)	Source-only (header library)	No open riscv64 correctness bugs; vectorization work still pending merge
dragonbox	`third_party/dragonbox/src` - fast float-to-string conversion	Critical (runtime)	Header-only; not independently packaged in Ubuntu/Debian	No upstream riscv64 CI found; zero riscv/riscv64 issues or PRs (confirmed via GitHub issue search, 0 results)	Source-only (header library)	None known - pure portable C++ numeric algorithm, no ISA-specific code
temporal_capi	Temporal calendar/date-time support (Rust)	Critical (runtime)	`riscv64gc-unknown-linux-gnu` target available via `rustup target add` since Rust 1.60 [NEEDS VERIFICATION: single-source, not re-confirmed this pass]	Not independently researched this session	Rust target, no standalone release relevant to V8	No blocking issues found
simdutf	`third_party/simdutf` - SIMD Unicode transcoding/Base64	Critical (runtime)	Found: Debian sid `libsimdutf33`/`libsimdutf-dev` 8.2.0-1 riscv64 (Ubuntu noble lacks it; 26.04 not independently re-checked)	Yes - 3 dedicated riscv64 CI workflows (VLEN 128/256/1024, QEMU), fuzzing included	Source-only upstream; Debian packaged	No open correctness bugs currently blocking. Base64 encode SIMD unmerged (PR #996); Base64 decode has no RVV implementation at all (issue #380, open since 2024); PR #890 (UTF-16/UTF-8-with-replacement RVV) stalled
Highway	`third_party/highway/src` - portable SIMD abstraction (RVV 1.0 backend)	Optional (runtime)	Found: Ubuntu 26.04 resolute `libhwy-dev`/`libhwy1t64` 1.3.0-2 riscv64	Build-only CI gate - riscv64 CI exists (`multiarch.yml`, QEMU, RVV enabled) but `ctest` has `continue-on-error: true`, so failing tests never block merges	Source-only; distro 1.3.0-2 is one release behind upstream 1.4.0	Open: #2854 (mold-linker segfaults on `.riscv.attributes` string), #2542 (no FMA on SCALAR/EMU128-RISC-V), #2793 (HwyDemoteTest failure on GCC 15) [NEEDS VERIFICATION: carried from prior pass], #2738 (incorrect `-march` on RVA23 profile targets) [NEEDS VERIFICATION: carried from prior pass]; RVV runtime dispatch is Clang 19+ only, no GCC path
zlib	`third_party/zlib` - DEFLATE compression	Optional (runtime)	Found: Ubuntu Noble 24.04 `zlib1g`/`-dev`; Debian sid `1:1.3.dfsg+really1.3.2-3`; Arch RISC-V packaged	riscv64 CI exists but is OpenBSD-only (`others.yml`, via vmactions/QEMU) - not in the Linux cross-compile matrix	Source-only upstream; widely distro-packaged	No correctness bugs. RVV-accelerated Adler32 (PR #1099, complete and tested on SG2042) unreviewed for 8+ months - maintainer has a documented multi-year pattern of not reviewing architecture-SIMD PRs (a 6-year-unanswered Power8 precedent). No RISC-V CRC-32 hardware-accel path exists (unlike aarch64)
libunwind	LLVM `libunwind` - stack unwinding	Optional (runtime)	Available for riscv64 via LLVM 17+ [NEEDS VERIFICATION: single source]	Not independently researched this session	Distro-packaged via LLVM toolchains	No V8-specific blocking issues found
libpfm4	PMU-based profiling support	Optional (runtime)	Gap: no RISC-V PMU event tables exist. `lib/events/` contains tables for AMD, Intel, ARM, IBM Cell only [NEEDS VERIFICATION: carried from prior pass, not independently re-checked this session]	No tracked issues or PRs for riscv64 support; no contribution in progress	Source library, no riscv64-relevant release status found	Hardware performance-counter profiling workflows depending on libpfm4 (including V8’s own benchmark infrastructure) are blocked on riscv64 until event tables are contributed
perfetto	Tracing/profiling	Optional (runtime)	Not independently researched this session	Issue #936 (stack-unwinding failure on riscv64) resolved November 2024; no currently open riscv64 issues found [NEEDS VERIFICATION: carried from prior pass]	Distro/source	No current blockers identified
GN	Build system generator	Critical (build)	Data not available: not independently researched this session; GN runs on the build host, not the target, so its own riscv64 support matters only for native riscv64-hosted builds	Data not available	Source-only, Chromium-maintained	No riscv64-specific findings this session
Ninja	Build execution tool	Critical (build)	Data not available: not independently researched this session; Ninja is a portable, widely cross-platform C++ tool commonly packaged for riscv64 by distros, but this was not directly verified	Data not available	Distro-packaged generally	No riscv64-specific findings this session
LLVM	Clang toolchain (used for simulator builds and native Clang riscv64 builds)	Critical (build)	Clang riscv64 cross-compilation support exists and is used for simulator builds per Section 5; no minimum version is pinned by V8 for riscv64 specifically	Data not available beyond what Section 5 documents	DEPS pins a CIPD-distributed prebuilt Clang, architecture-generic	No riscv64-specific blocking issues found this session
GCC	Used for native (non-simulator) riscv64 builds (`is_clang=false` via the `gcc` mixin)	Critical (build)	riscv64 cross-GCC toolchains (`riscv64-linux-gnu-` prefix) are widely available via Debian/Ubuntu packaging; no V8-pinned minimum version	Data not available	Distro-packaged	No riscv64-specific blocking issues found this session
googletest	C++ test framework	Critical (test)	Header/source library, portable C++, not independently researched this session	Not independently researched this session	Source-only, widely distro-packaged	No riscv64-specific issues found
re2	Not in V8’s own DEPS directly, but the dominant downstream consumer of Abseil, included for Abseil blast-radius context	Indirect (via Abseil)	Found: Ubuntu 24.04 Noble `libre2-10`/`-dev` riscv64; Debian `20251105-1+b1` installed	No upstream CI (zero riscv64 references in 7 workflow files); builds cleanly, pure portable C++	Source-only upstream; distro packaged	No re2-specific bugs; inherits Abseil’s open #1702 (atomics link), #2002 (SEGFAULT), and #2142 (SwissTable `kWidth==8` test failure, affects riscv64/aarch64/ppc64le/loongarch64)
cpu_features	`third_party/cpu_features` - runtime ISA-extension detection feeding SIMD/JIT dispatch (indirect, via Highway/simdutf’s dependency chain)	Indirect	Partial: not in Ubuntu 24.04; is in Debian sid (`libcpu-features-dev` 0.11.0-1, riscv64 built on rv-manda-02)	Yes - dedicated GitHub Actions `riscv_linux_cmake.yml`, QEMU-based, scheduled plus every push/PR	Source-only releases (no binary assets for any arch)	Cannot runtime-detect Zba/Zbb/Zbc/Zbs or Zfh/Zfhmin or BF16 (3 PRs stalled 4-10 months: #368/#369/#447); silent false-negative bug in Zicsr/Zifencei detection on kernels 6.5+ (draft fix PR #468, unreviewed)
double-conversion	Grisu/Bignum dtoa, originally extracted from V8 itself, also vendored inside ICU (indirect, via ICU)	Indirect	Found: Ubuntu Noble 24.04 `libdouble-conversion3`/`-dev` 3.3.0-1build1 riscv64 [NEEDS VERIFICATION for 26.04 specifically]; Debian ports 3.4.0-1+b1	Not exercised by any upstream CI job (no riscv64 CI at all), but functionally complete: pure scalar C++, `__riscv` arch macro merged 2016	Source-only; Debian ports/Ubuntu packaged	None riscv64-specific. One open cross-platform correctness bug (PR #304, hex-float ULP rounding) affects all architectures equally
FP16	`third_party/fp16/src` - half-precision float conversion (indirect, numerics chain)	Indirect	Header-only; not independently packaged	One open PR (#45, “Add RISC-V QEMU test coverage,” Jun 2026) indicates no riscv64 CI currently exists	Source-only (header library)	No correctness bugs found; CI coverage gap is the only identified item

Key takeaways: no dependency in this set has a hard riscv64-blocking defect - everything builds and functions on riscv64 today. The recurring pattern is CI rigor gaps (Highway and zlib both run riscv64 under QEMU but do not gate merges on test results) and unmerged performance work (Highway’s mold-linker issue, zlib’s stalled RVV Adler32 PR, simdutf’s missing Base64 RVV decode, cpu_features’ stalled bitmanip-detection PRs). Abseil is the highest-leverage dependency to watch: it sits underneath Highway, re2, and much of V8’s own C++ runtime, and carries two multi-year-old open riscv64 bugs plus a CRC32C hardware-acceleration PR stalled purely on Google obtaining RISC-V test hardware.

11. Known Bugs and Active Issues

Note on scope: v8/v8’s GitHub mirror has Issues enabled but empty/unused (0 results for both riscv and riscv64 searches); the active public issue tracker for the RISC-V port is riscv-collab/v8, the historical RISC-V staging repo. Real upstream bug tracking lives on crbug.com (Chromium Monorail/Buganizer), which is not reachable via GitHub’s API and was not independently searchable this session - upstream bugs affecting riscv64 may exist there and are not reflected below.

Issue	Title	Status	Notes
#701	Octane failed on Unmatched	Open since 2022-06-30	Correctness failures on real hardware: NavierStokes checksum fail, PdfJS wrong output, SunSpider failures, plus low perf scores (Section 6.11)
#705	Tracking test262 and mozilla test status	Open, tracking	-
#704	v8 run test failed	Open	-
#702	rv32 debug stress mode failed	Open	RV32G (deprecation target)
#696	Record regression status for commit ddc083	Open, regression tracking	-
#695	cctest RunWasmLiftoff_I32Binop_DivS fails	Open	RV32G
#694	How to cross compile v8 for riscv32	Open, documentation gap	-
#670	regress-crbug-1041232.js fails on native test mode	Open	RV32G
#669	regress-crbug-1209152.js fails on native test mode	Open	RV32G
#666	Test riscv32 native release	Open	RV32G tracking
#630	cctest test-macro-assembler-riscv32/CompareI	Open	RV32G
#574	Integer division by power of 2 should use shift	Open	riscv64 performance optimization
#374	Update instruction latencies	Open since 2020-12-31	Scheduler uses MIPS-derived latency values (Section 6.4), assignee qjivy

5 of these 13 open items are RV32G-labeled, consistent with the pending riscv32 removal (May 2026). Issue #701 is the only open benchmark-specific failure on real riscv64 hardware; #574 is the only open riscv64-specific performance-optimization ticket. NaN/floating-point correctness search turned up only closed issues (riscv-collab/v8#97, “Riscv64-simulator can’t handle a float value which isn’t NaN-boxed,” and #643, RunBitcastInt32ToFloat32 cctest) - no open NaN-specific bugs currently.

Active Gerrit CLs

CL	Title	Status	Blocking factor
7953190	fp16 vfadd/vfsub/vfmul/vfdiv (Zvfh)	Code-complete, CQ dry-run passed	Needs a general V8 owner Code-Review+2 (only RISC-V OWNER +1 so far)
7203127	Separate Liftoff FP and SIMD registers	Stalled 3+ months	No reviewer engagement
7500131	Fix Sub32 immediate/INT_MIN handling	Stalled since 2026-01-20	Unresolved correctness objection, no reproducer
6874383	Replace auipc+jalr with jal	WIP since 2026-02-03, stalled	Safepoint-table integrity concern
7932348	“fix” (WIP scratchpad)	Open, 2026-06-12	No description, no reviewers; large net-negative diff [NEEDS VERIFICATION: single source, not re-confirmed this pass]

12. Objections and Upstream Blockers

Is the upstream maintainer team stable enough to depend on? The functional RISC-V backend is maintained operationally by two ISCAS/PLCT Lab engineers, Yahan Lu and Ji Qiu, plus Kasper Lund (Meta) as a third OWNER. There is no Google commitment to continuity: Google’s stated policy (Section 3) is that RISC-V breakage is the RISC-V team’s responsibility, not Google’s. The approximately 25% upstream-tracking overhead figure quantifies the exposure: roughly one-quarter of all RISC-V V8 effort over a recent six-month window went to chasing upstream changes rather than producing new capability. This is a single-organization concentration risk - if ISCAS deprioritizes V8, the port degrades with each subsequent upstream change, since Google has no internal team positioned to absorb the work.

Does the simulator give adequate confidence for production deployments? No. Simulator-only upstream CI failed to catch a real-hardware vector-register save/restore bug (Section 6.9); it was found only through testing on physical hardware, outside the official CI loop. Organizations deploying V8 on physical RISC-V hardware need their own bare-metal or QEMU validation to catch classes of bugs the simulator cannot.

Is the Sub32 overflow bug (CL 7500131) a production risk? It is a latent correctness risk in 32-bit integer subtraction around INT_MIN boundary values. The fix has been stalled with an unresolved objection since January 2026, and no test case demonstrating a failure has been contributed, so the practical risk cannot be quantified without a reproducer. This warrants direct investigation before relying on V8 for arbitrary JavaScript execution on riscv64.

Is there a path to official Google support for riscv64? Data not available: no public statement from Google’s V8 team committing to officially support riscv64 was found in either research pass. Official support (per docs/official-support.md) is tied to CI-bot presence and is implicitly reserved for architectures Google itself runs in production; no evidence was found that Google runs RISC-V hardware in production at a scale that would motivate elevating riscv64’s tier.

What is RISE’s actual involvement? RISE Project’s only documented touchpoint with V8 is a single blog post, “A Glimpse Into V8 Development for RISC-V” (published 2025-12-09, authored by Florian Loitsch, Ji Qiu, Kasper Lund, Yahan Lu, and Zhijin Zeng). Of the 35 posts on the RISE blog, only this one mentions V8. There is no RISE GitHub/GitLab repository for V8 (the full 26-repo riseproject-dev org listing contains none), no evidence V8 CI uses RISE RISC-V Runners, and V8 is absent from the RISE Python wheel_builder’s 87-package list. The post itself does not claim RISE funded the described work - it reads as ecosystem reporting on community engineering progress, not a RISE-commissioned project. RISE membership is organizational, not project-level: V8 itself is not a RISE member or project. The connection to RISE is indirect, through Google (a RISE Premier Member, which owns V8 overall) and ISCAS (a RISE General Member, whose engineers - Ji Qiu and Yahan Lu - are the two primary riscv64 maintainers).

Are there performance numbers for RISC-V vs. ARM64 or x86-64? No cross-architecture numeric benchmark comparison (JetStream, Speedometer, or any other suite) is publicly available. JetStream suite completion on RISC-V is documented as a capability milestone, but no score is published anywhere found, by V8, RISE, SpacemiT, or any independent source.

13. Readiness Assessment

Color: blue (n/a)
Release provider: none
Justification: V8 has a mature, upstream-maintained riscv64 backend (89 architecture-specific files across all four JIT tiers, 913 commits, full JetStream suite passing) exercised by dedicated LUCI CI builders (“V8 Linux - riscv64 - sim” / “sim - debug” / “sim - pointer compression” in infra/testing/builders.pyl) that build and run the full test suite via an in-process RISC-V simulator and pass consistently, per the RISE December 2025 post (riseproject.dev). V8 publishes no binary releases for any architecture (github.com/v8/v8/releases is empty, confirmed directly), so no upstream riscv64 artifact exists - this caps the grade at blue rather than green. V8 is a general-purpose JS/Wasm runtime, not a project whose value proposition is purely architecture-specific speedup over a scalar fallback, so the optimization-purpose modifier does not apply and no separate optimization-level rating is given.
Pending work that could change the grade: Open Gerrit CLs: 7953190 (fp16/Zvfh arithmetic, code-complete, blocked only on a V8-owner Code-Review+2), 7500131 (Sub32/INT_MIN overflow fix, stalled since January 2026 on an unresolved correctness objection with no reproducer), 6874383 (auipc+jalr to jal optimization, stalled on a safepoint-table integrity concern), 7203127 (Liftoff FP/SIMD register separation, stalled 3+ months). No native-hardware or QEMU-based upstream CI exists - only simulator CI - and this gap let a real vector-register save/restore bug ship past CI and surface only on physical hardware (per the RISE blog). An independent, non-upstream Jenkins buildbot (ci.rvperf.org/view/V8/) run by the RISC-V community does real-hardware testing but is not part of official V8 CI. RISE’s only documented touchpoint with V8 is the single December 2025 blog post; no RISE repo, RISE-funded grant, or RISE Python-wheel listing exists for V8, though ISCAS (a RISE General Member) employs the two primary riscv64 maintainers (Ji Qiu, Yahan Lu), and Google (RISE Premier Member) owns V8 overall.

14. Investment Analysis

Before sizing: RISE’s only documented contribution to V8 is reporting on community engineering work already done by ISCAS/PLCT Lab and SpacemiT engineers in a single blog post - there is no RISE-funded V8 work, RISE repository, or RISE infrastructure usage to subtract from the estimates below. All items below represent genuinely unfunded, uncovered work.

14.1 Functional Enablement

Work Item	Effort (person-weeks)	Priority	Notes
Land CL 7953190 (fp16 vfadd/vfsub/vfmul/vfdiv)	1	High	Code-complete, CQ dry-run passed; blocked only on a V8 owner Code-Review+2. A reviewer with V8 owner status needs to engage.
Fix Sub32 overflow bug (CL 7500131)	2	High	Requires a test case demonstrating INT_MIN failure, addressing the unresolved correctness objection, and re-upload.
Implement Zabha (byte/halfword atomics)	3	Medium	Remove the TODO in `liftoff-assembler-riscv64-inl.h`; implement Zabha instructions; requires Zabha-capable hardware to validate.
Implement Zbb ror/rol in macro-assembler	2	Medium	No Gerrit CL exists; the one prior attempt failed on CLA via the wrong contribution channel (GitHub mirror, not Gerrit). Straightforward instruction addition via the correct channel.
Separate Liftoff FP and SIMD registers (CL 7203127)	3	Medium	CQ dry run passed; stalled 3+ months. Needs a reviewer to re-engage and a V8 owner LGTM. Correctness/ABI improvement.
Harden shadow stack (Zicfiss hardware path)	4	Low	Current hardware path is `UNREACHABLE()`. Requires Zicfiss-capable hardware. Low priority until such hardware is common.

14.2 Performance Optimization

Work Item	Effort (person-weeks)	Priority	Notes
Update instruction scheduler latency tables	4-8	Medium	Current tables are MIPS-derived (riscv-collab/v8#374). Requires latency characterization on a real RISC-V microarchitecture. Benefits out-of-order cores.
Land auipc+jalr to jal optimization (CL 6874383)	2	Medium	CQ dry run passed; stalled on a safepoint-table concern. Implementing the suggested `nop+jal` approach as a separate CL would unblock it.
Establish riscv64 vs. arm64/x86-64 benchmark baseline	3	High	No public numeric comparison exists anywhere. Investment decisions cannot be evidence-based without this. Requires bare-metal riscv64 hardware running JetStream/Speedometer with results published.
simdutf RVV runtime dispatch and Base64 decode	5	Medium	Upstream simdutf issue, not V8-internal, but affects V8 string transcoding performance; Base64 decode currently has no RVV path at all (issue #380).

14.3 CI/CD Infrastructure

Work Item	Effort (person-weeks)	Priority	Notes
Bare-metal or QEMU riscv64 CI builder	3	High	All upstream CI is simulator-only. A real-hardware or QEMU builder would have caught the RVV register save/restore bug before it shipped. Every RVV patch today is unvalidated against real hardware in official CI.
Sanitizer builds (ASAN at minimum)	4	Medium	No ASAN CI exists for riscv64. Would help find memory errors in the backend. Requires confirming ASAN support in Clang for riscv64 and creating a builder config.

14.4 Ecosystem Enablement

Work Item	Effort (person-weeks)	Priority	Notes
libpfm4: RISC-V PMU event tables	6-10	High	Zero RISC-V event tables exist today. V8’s own profiling/benchmarking workflows that depend on hardware counters are blocked on riscv64. Requires PMU documentation for target silicon and an upstream libpfm4 contribution.
simdutf: Base64 decode RVV implementation and merge PR #996/#890	3	High	Base64 decode has no RVV path at all; encode and UTF transcoding RVV work is unmerged. Affects V8 string transcoding performance/correctness coverage.
Highway: fix mold-linker and -march RVA23 issues (#2854, #2738)	3	Medium	Upstream Highway contributions; affect `simdutf`’s build correctness on current toolchains and newer RISC-V profile targets.
Abseil: push CRC32C hardware-acceleration PR (#1986) to completion	2	Medium	Stalled purely on Google obtaining RISC-V test hardware for the PR author, not on code quality. Affects V8’s own runtime hash/CRC paths indirectly via Abseil.

14.5 Summary Table

Area	Work Item	Effort (person-weeks)	Owner	Priority
Functional	Land CL 7953190 (fp16 SIMD arithmetic)	1	Engineer with V8 owner status	High
Functional	Fix Sub32 overflow bug (CL 7500131)	2	RISC-V backend engineer	High
Functional	Implement Zabha byte/halfword atomics	3	RISC-V backend engineer	Medium
Functional	Implement Zbb ror/rol in macro-assembler	2	RISC-V backend engineer	Medium
Functional	Separate Liftoff FP and SIMD registers (CL 7203127)	3	RISC-V backend engineer + V8 owner reviewer	Medium
Functional	Harden Zicfiss hardware shadow stack	4	RISC-V backend engineer	Low
Performance	Establish riscv64 vs. arm64/x86-64 benchmark baseline	3	Performance engineer + hardware access	High
Performance	Update instruction scheduler latency tables	4-8	Microarchitecture engineer	Medium
Performance	Land auipc+jalr to jal optimization (CL 6874383)	2	RISC-V backend engineer	Medium
Performance	simdutf RVV runtime dispatch and Base64 decode	5	simdutf upstream contributor	Medium
CI/CD	Bare-metal or QEMU riscv64 CI builder	3	Infrastructure engineer	High
CI/CD	ASAN sanitizer CI build	4	Infrastructure engineer	Medium
Ecosystem	libpfm4 RISC-V PMU event tables	6-10	PMU/hardware specialist	High
Ecosystem	simdutf Base64 decode RVV implementation	3	simdutf upstream contributor	High
Ecosystem	Highway mold-linker/RVA23 fixes	3	Highway upstream contributor	Medium
Ecosystem	Abseil CRC32C hardware-acceleration PR to completion	2	Abseil upstream contributor + Google RISC-V hardware access	Medium

V8