From Sea of Nodes to Turboshaft: A Step-by-Step Migration Guide for Compiler Engineers

By ✦ min read

Introduction

For over a decade, V8’s top-tier optimizing compiler Turbofan relied on an unconventional intermediate representation known as the Sea of Nodes (SoN). While pioneering, SoN introduced complexities that eventually led the V8 team to pivot to a more traditional Control-Flow Graph (CFG)–based IR called Turboshaft. This guide walks through the key steps and decisions that made that migration successful, drawing from real engineering challenges and solutions. Whether you’re maintaining a production compiler or designing a new one, these steps can help you plan a similar transition.

What You Need

• Understanding of compiler IRs: Basic knowledge of control-flow graphs and sea-of-nodes concepts.
• Familiarity with V8’s architecture: Especially Turbofan, Crankshaft, and the pipelines for JavaScript and WebAssembly.
• Existing compiler codebase: Preferably a production compiler with a SoN-based IR (or similar) that you intend to replace.
• Team with IR design and backend optimization experience.
• Performance regression testing framework.
• Documentation of current IR limitations: e.g., control-flow rigidity, deoptimization loops.

Step-by-Step Migration Guide

Step 1: Audit the Existing IR’s Pain Points

Begin by cataloging the shortcomings of your current intermediate representation. In V8’s case, the Crankshaft compiler suffered from:

• Excessive hand-written assembly per architecture (x64, ia32, arm, arm64).
• Inability to introduce new control flow during lowering (control flow was frozen after graph building).
• No support for try-catch constructs.
• Severe performance cliffs and bailouts (e.g., 100× slowdowns).
• Frequent deoptimization loops where the compiler re-optimized with the same failing assumptions.

Document these issues thoroughly. They will serve as the justification for your migration and as criteria for the new IR.

Step 2: Define the Target IR’s Core Design

Based on the audit, decide on a new IR that addresses the key weaknesses. V8’s team chose a Control-Flow Graph (CFG) representation, naming it Turboshaft. Key design decisions:

• Use explicit basic blocks and edges to represent control flow.
• Support incremental lowering with control flow introduction (e.g., lowering a high-level Add to a branch based on types).
• Reduce architecture‑specific code by leveraging a common high-level IR and lowering to architecture‑neutral instructions.
• Enable easier support for exception handling (try-catch).

Create a detailed specification for the new IR, including node types, constraints, and how it will integrate with existing frontends and backends.

Step 3: Build a Prototype Backend for One Pipeline

Start small: implement the new IR for a single, well‑defined pipeline. V8 first applied Turboshaft to the JavaScript backend of Turbofan, leaving the frontend and builtins on the old IR. This minimized risk while validating the design.

• Implement the core graph construction, scheduling, and code generation.
• Write a small set of optimization passes that work on the CFG (e.g., constant propagation, dead code elimination).
• Integrate with the existing compiler framework, ensuring you can still fall back to the old IR if needed.

Step 4: Replace the Frontend with a CFG‑Based IR

For the JavaScript frontend, V8 created Maglev, another CFG‑based IR that feeds into Turboshaft. This step is critical because the frontend determines the initial graph structure.

• Design a simple, high‑level CFG IR that can be quickly generated from the AST.
• Keep the frontend decoupled from the backend to allow independent evolution.
• Ensure the generated graph can be efficiently translated to Turboshaft’s lower‑level nodes.

Test with common JavaScript patterns and measure impact on compile time and code quality.

Step 5: Migrate the WebAssembly Pipeline End‑to‑End

WebAssembly is often simpler than JavaScript because of its static type system and explicit control flow. V8 switched the entire WebAssembly pipeline (from binary decoding to code generation) to Turboshaft. Steps:

• Write direct translation from Wasm opcodes to Turboshaft CFG nodes.
• Optimize for Wasm‑specific features (e.g., structured control flow, memory operations).
• Validate correctness using the Wasm spec tests and performance benchmarks (e.g., Emscripten, game engines).

This complete pipeline migration provided early confidence in the new IR’s reliability.

Step 6: Gradually Replace the Builtin Pipeline

Builtins (internal functions used by JS semantics) were still encoded in the old SoN representation. V8’s team started rewriting them to use Turboshaft, one by one. Tips for this step:

• Identify builtins that are performance‑sensitive (e.g., Array operations, String methods).
• Leverage the new IR’s ability to introduce control flow to implement complex builtin logic more naturally.
• Keep the old builtins as a fallback until migration is complete.

Step 7: Remove Old IR Dependencies and Clean Up

Once all major pipelines use the new IR, remove Sea of Nodes from the codebase. This reduces maintenance burden and code size. Ensure:

• All uses of the old IR are deleted (graph building, passes, code generation).
• Test coverage is high to catch regressions.
• Document the old IR’s deletion and update developer guides.

Tips for a Successful Migration

• Start with a clear motivation: Use your pain‑point audit to rally the team and justify the effort.
• Incremental replacement is safer: Replace one pipeline at a time to isolate issues.
• Invest in testing infrastructure: Automated regression tests for performance and correctness are essential.
• Design for flexibility: A CFG‑based IR is easier to reason about and extend than a sea of nodes.
• Watch out for deoptimization loops: In the old system, speculative optimizations caused repeated bailouts. The new IR should avoid re‑speculating on the same failed assumptions.
• Communicate changes widely: V8’s blog posts and documentation helped the community understand the shift.
• Expect a multi‑year effort: V8’s migration took nearly three years. Plan for long‑term support of both IRs during the transition.