Demand-Driven Routing Space for Lattice-Surgery Compilation

Introduction

Fault-tolerant quantum programs use many physical qubits to protect each logical qubit [23, 33]. Surface-code experiments have demonstrated improved logical memory as the code distance increases [31, 32]. In the planar surface code, a logical qubit occupies a patch of physical qubits, represented here by a tile [46, 64]. On a planar device, lattice surgery implements logical interactions by merging and splitting neighbouring patches [16, 22, 46, 64]. Distant qubits therefore need intervening space for their interactions. A compiler must determine both where logical qubits reside and how their interactions use the available space. These decisions determine the required chip area and the number of execution steps, whose product is the space–time volume [26, 27].

Exposing this cost efficiently is important for algorithm–architecture co-design [69]. Analytical resource estimators predict execution cost without constructing the paths needed to establish routing feasibility [5, 39, 48]. More detailed compilers construct three-dimensional realizations using SAT synthesis, topological transformations, or path search [7, 36, 62, 79, 88].

Nevertheless, minimizing lattice-surgery resource costs is computationally hard in general [40]. Therefore, compilers such as DasCot [71] and LibLSQECC [59, 60, 84] use the patch-layer abstraction that represents execution as routing steps on a two-dimensional tile grid, enabling algorithm designers to efficiently compare circuit formulations.

However, routing feasibility can come at the cost of substantial idle space. The DasCot layout evaluated here fixes data-qubit positions, separates neighbouring sites, and reserves a border around the array, as Figure 1b shows. Each CX or T gate uses a path of free tiles. The reserved space limits contention, keeping routed step counts close to the depth imposed by circuit dependencies. Yet only 5–27% of the free tiles carry paths in an average step across our application benchmarks. The resulting programs therefore reserve physical-qubit capacity that most execution steps leave idle.

Reducing chip area is an important yet challenging problem. Indeed, sharing lanes saves area but can introduce routing conflicts and serialize gates [64]. Conversely, routes that permit more gates to execute together may use different lanes and prevent the layout from being compacted. Changing qubit placement can accommodate different routing demands, but movement adds execution time. These tradeoffs make routing-space allocation an architecture–compiler co-design problem: the architecture must expose opportunities to share and rearrange routing space, while the compiler must exploit those opportunities without excessive contention or movement.

To address this problem, we present a co-designed dynamic architecture and lattice-surgery compiler.¹ Our architecture allows qubits to share routing lanes and their physical

spacing to change between execution stages. The compiler couples demand-driven floorplanning and contention-aware placement with scheduling, routing, and compaction. Unlike previous works that route qubits after the mapping is given, we use traffic to dynamically rearrange qubits and allocate lanes. Experimental results show that this dynamic execution model not only reduces the space-time volume by 55.6% but also speeds up the compilation by 75.5×, compared with one of the state-of-the-art static models.

Lanes Should Follow the Traffic!

Our method is inspired by reversible road lanes in Figure 2a, with more lanes leading toward work in the morning and toward home in the evening. In this section, we use the running example in Figure 1a to demonstrate the advantages of on-demand routing lane allocation and dynamic architecture, thereby motivating our method. The circuit has eight qubits and six gates: five two-qubit CX gates and one T gate. The gates $g_1$, $g_3$, $g_5$, $g_6$ must execute in order, requiring four steps. Gate $g_2$ can run alongside $g_1$, and $g_4$ alongside $g_3$. In the snapshots, orange paths connect pairs of qubits, and the green path connects a qubit to an auxiliary state required by its T gate. For the static layouts in Figure 1, we specify the qubit placements for illustration and show only the first two routed steps.

Static, conservative layout (Figure 1b). A simple way to complete routing is to conservatively reserve space between neighbouring qubits and around the array [71]. This produces a $9 \times9$ grid. The routes within each of the two snapshots do not overlap, allowing both gates to run simultaneously. All six gates finish in four steps, giving a space-time volume of $9 \times9 \times4 = 324$ tile-steps. Nevertheless, as the hatching shows, many rows and columns remain unused throughout execution.

Static, on-demand layout (Figure 1c). One can reduce chip area by removing unused lanes, such as column 0 and row 8 in Figure 1b. A more systematic approach allocates routing space on demand, yielding the $4 \times7$ layout shown in Figure 1c. The volume falls to $4 \times7 \times4 = 112$ tile-steps without delaying any gate. This saving does not require qubit movement. However, as the execution depth grows, lanes are less likely to stay completely empty. All four rows must remain in this example; row 3, for instance, is needed in the last two steps.

Dynamic routing space (Figure 2b). Based on this observation, our method adopts a dynamic architecture. By allowing different layouts at different stages, we can remove lanes that are unused within a partition of the entire circuit. As shown in Figure 2b, changing qubit spacing after the first two steps shifts routing space from above to below the qubits. The first stage uses a $3 \times7$ layout, and the second uses $3 \times5$. This way, both layouts fit on one $3 \times7$ chip. This area reduction incurs a movement cost between stages. Recent developments in walking surface codes support parallel movement [70]; in this example, under our movement model, the transition adds one execution step. All four gate steps remain unchanged, so volume becomes $3 \times7 \times(2 + 1 + 2) = 105$ tile-steps.

Patch-Layer Execution Model

This section provides preliminary background on patch-layer execution. Due to space limits, we refer readers to Horsman et al. [46] and Litinski [64] for a more detailed and formal introduction.

Circuit as a Traffic Dependency Graph

We take a Clifford+T circuit with $n$ declared data qubits, all resident throughout execution, and extract a directed acyclic traffic dependency graph (TDG). Each vertex represents an operation that requires routing: a CX between control and target qubits, or a T/T$^{\dagger}$ gate between a data qubit and a fresh magic state. Figure 9a shows an example TDG. Single-qubit Clifford gates such as H, S, X, and Z are not represented as routed operations and are assigned no routing or execution cost in our patch-layer model. This modeling assumption omits Clifford implementation and frame-management overhead, whose physical cost depends on the chosen protocol [48, 67].

Vertices: Both types of routed operations require connectivity between patches, as illustrated in Figure 3. For a CX (Figure 3a), a temporary ancilla patch is initialized to $|+\rangle$. Two successive merge/split operations measure its joint ZZ parity with the control and XX parity with the target, before the ancilla is read out [67]. A T gate (Figure 3b) consumes a fresh magic state $|M\rangle= (|0\rangle+ e^{i\pi/4}|1\rangle)/\sqrt{2}$ through a CX and readout, with an outcome-dependent S correction [9]. It therefore requires traffic from the data qubit to any magic-state patch. We count each gate’s ordered surgery operations as one routed step, or simply step.

Edges: An edge $g_i \to g_j$ requires $g_i$ to finish before $g_j$ starts. The dependency depth $D$ is the number of gates on a longest TDG chain and is a lower bound on the number

of routed steps. The TDG may leave commuting gates unordered. For example, CX gates sharing only a control or only a target can execute in either order, provided their dependencies on other gates are respected. Commutation permits reordering, but does not by itself permit concurrent execution: gates sharing a data tile must still execute in different routed steps. Likewise, separate magic-state consumptions introduce no circuit dependency between otherwise independent gates, but remain subject to magic-state availability.

Patch-Layer Abstraction

A tile connectivity graph (TCG) records qubit placements and the tile connectivity allocated to gates in one routed step, such as the first step of Figure 1b. The output program consists of a sequence of TCGs. All gate steps use the same fixed grid of $H$ rows and $W$ columns.

Qubit placement. A qubit placement is a tuple $(r,c,o)$, where $r$ and $c$ are zero-based tile coordinates and $o \in\{\mathrm{TB}, \mathrm{LR}\}$ is the orientation. The labels name the sides carrying Z boundaries: top and bottom for TB, or left and right for LR. The remaining two sides carry X boundaries. Figure 4 illustrates both orientations using distance-3 surface-code patches.

Traffic routing. In each TCG, a vertex denotes a data-qubit tile, a routing tile used in that step, or a supplied magic-state tile. Unused routing tiles are omitted from the graph, but remain part of the charged chip area. An undirected edge connects adjacent tiles participating in a gate’s lattice-surgery operations, abstracting two consecutive merge/splits. Figures in this paper include arrows just to differentiate control and target of CX, because they must connect to different types of boundaries. Besides, routes executed in the same step must be tile-disjoint, including their data-qubit and magic-state endpoints.

For example, in the first step of Figure 1b, $g_2$ connects $g_3$ at $(2,6)$ to $g_7$ at $(4,6)$ through routing tiles $(3,6)$, $(3,5)$, and $(4,5)$. These five vertices and the edges joining consecutive tiles form one connected component.

Dynamic Architecture

Dynamic routing-space allocation couples architecture design with compilation. Using less routing space reduces area, but can introduce contention and serialize gates. Changing qubit spacing can accommodate different routing demands, but movement adds execution time. This section specifies the dynamic architecture constraints and formulates the space–time volume objective.

Virtual Floorplan and Dynamic Mapping

As shown in § 2, dynamic qubit placement allows routing space to adapt to changing circuit traffic. Ideally, qubits could be rearranged arbitrarily between steps, but this could introduce significant movement overhead. To strike a better balance, our method draws on walking surface codes for parallel movement [70] and separates qubit assignment from physical spacing. A virtual floorplan fixes the array shape, qubit-to-site assignment, and qubit orientations throughout execution. Its physical mapping determines the spacing between qubit rows and columns and may change between stages.

More specifically, $\pi(q_i) = (u_i, v_i, o_i)$ assigns qubit $q_i$ a distinct site $(u_i, v_i)$ in an $h \times w$ virtual array and a fixed orientation $o_i$, with $hw \ge n$. At execution step $t$, a row-coordinate vector $r_t$ of length $h$ and a column-coordinate vector $c_t$ of length $w$ map virtual indices to physical tile coordinates:

Both vectors contain strictly increasing integer coordinates within the fixed chip. Changing an entry moves the qubits in the corresponding virtual row or column together, while preserving their order. Gaps between mapped rows and columns determine routing-lane widths. In Figure 5, changing $c_t$ from $(1, 3, 4)$ to $(1, 2, 4)$ redistributes the internal vertical routing space without changing the virtual floorplan.

Execution is partitioned into $K$ stages, each a consecutive group of routed steps that uses one physical mapping. Walks between stages must preserve row and column order and remain within the fixed chip.

Objective Function

We minimize the space–time volume: the fixed grid area multiplied by the total number of execution steps.

Let $H_s$ and $W_s$ denote stage $s$’s dimensions, including space for magic-state delivery, and let $T_s$ be its number of routed

steps. The fixed chip must accommodate every stage, while total execution time includes both gate steps and walks. The volume is

Different stages may determine the maximum height and width. Padding around smaller stages is charged at every step.

Let $(r_i^{(s)}, c_i^{(s)})$ denote the physical coordinates of qubit $q_i$ in stage $s$. We model the duration $\delta_s$ of the walk after stage $s$ as the largest absolute row or column displacement of any qubit:

for $1 \le s < K$. The walk contributes $\delta_s$ steps to execution time. For the transition from Figure 5b to Figure 5c, only $q_1$ and $q_4$ move one tile left, giving $\delta_s = 1$. The one-step-per-tile cost is based on the recently developed walking surface code scheme, consistent with the optimistic movement estimate in FLASQ [48].

Demand-Driven Compiler

The dynamic architecture requires scheduling, routing, and mapping to account for how their choices affect space–time volume. Scheduling must balance dependency progress against the routing space retained by each stage; routing should favor lane reuse; and mapping must anticipate both contention and compaction. The compiler coordinates these choices with stage formation to balance area savings against gate delays and movement overhead.

Exact joint optimization of placement, routing, and stage boundaries could fully exploit the architecture’s dynamism, but greatly enlarges the compilation search space. Searching this larger space can even yield worse solutions when compilation time is bounded. To balance solution quality and compile time, our method fixes a virtual floorplan, routes under lane budgets, and compacts each stage according to its routing demand. Figure 6 shows this workflow. We first introduce shape selection and lane budgets in § 5.1, then frontier routing in § 5.2, followed by qubit placement in § 5.3.

Demand-Driven Floorplanning

Floorplanning selects the virtual array’s shape and the routing space available within each stage. We first predict a shape from circuit demand, then bound stage dimensions with row and column lane budgets.

Shape selection. Since the input fixes the number of qubits $n$, we choose the virtual array’s aspect ratio. We consider $h = 1, \ldots, \left\lfloor\sqrt{n}\right\rfloor$ site rows and $w = \left\lceil n/h \right\rceil$ columns, selecting the shape with minimum predicted volume:

To estimate $\widehat{V}$, we use a throughput model inspired by Roofline [85]. Depending on the TDG’s gate demand and the chosen aspect ratio, execution can be limited by magic-state delivery or CX routing.

• Magic and CX demand. We group gates at their earliest steps allowed by the TDG. Let $m_{\mathrm{CX},j}$ and $m_{\mathrm{T},j}$ count the CX and T/T$^\dagger$ gates in group $j$, respectively.

• Magic and CX resources. Although lane allocation is determined during routing, we estimate throughput using a proxy: two T gates per site row per step, supplied by the two magic-delivery tiles at its ends, and one CX route per site row per step. As illustrated in Figure 7, this gives estimated throughputs of $2h$ T gates and $h$ CX gates per step.

Putting these together, a simplified volume estimate using the virtual area $h\times w$ is

The maximum selects the bottleneck, with at least one step per group. If neither throughput limits execution, the estimate reduces to $D\times h\times w$. The single-row shape attains the minimum virtual area $h\times w=n$; ties favor fewer site rows. Our shape-selection heuristic does not guarantee feasibility: it omits actual routing conflicts, compaction, and walks, and T traffic also competes for routing space. We evaluate its effectiveness against exhaustive configuration selection in § 6.2.

Lane budgets within a stage. For an $h\times w$ virtual floorplan, we next determine lane budgets $\Delta_H,\Delta_W$ that limit the additional rows and columns retained for routing and magic-state delivery:

Each stage initially retains only data-site coordinates. As illustrated in Figure 8, we route successive steps under these budgets using the selection rule in § 5.2, accumulating required coordinates and updating the ready gates after each step. If no route is selected in a nonempty stage, we close it and retry the same ready gates with fresh lane resources.

Lane budgets and routing choices are interdependent: routes determine lane demand, while budgets guide route selection and stage boundaries. We fix the budgets before routing to simplify route selection and stage partitioning (§ 5.2).

Compaction-Aware Frontier Routing

At routed step $t$, the dependency frontier $F_t$ contains unexecuted TDG gates whose predecessors have finished. The router selects a subset of frontier gates and one candidate path for each selected gate. Routes connect control Z to target X boundaries for CX, or a data Z boundary to a fresh magic-state tile for T. Selected routes cannot share data, routing, or consumed magic-state tiles. After committing a routed step, the compiler updates the frontier.

Routing algorithm should not simply maximize concurrency in the current step, as it does not necessarily minimize program volume. Indeed, executing several short dependency branches may delay a gate on a longer remaining chain. Likewise, routes spread across different lanes can prevent a stage from shrinking, even when they allow more gates to execute together.

Instead, we select routes using dependency criticality, the additional coordinates retained after compaction, and row and column budgets. For each frontier gate, we search paths in increasing order of bend count and retain at most one candidate. For T/T$^{\dagger}$ gates, the search is restricted to the nearest available magic-state tiles. Compared with a general shortest-path search, this restriction reduces search effort and favors low-bend routes, but may miss feasible routes.

Compatibility and criticality. The candidates define an undirected conflict graph $C_t$. Each vertex represents a candidate route. An edge joins two vertices when their routes share a data, routing, or consumed magic-state tile. An independent set therefore selects mutually compatible routes.

We assign each gate $g$ a criticality $\kappa_g$, the length of the longest remaining TDG chain starting at $g$, including $g$ itself. Writing $\operatorname{succ}(g)$ for its immediate successors,

Without lane costs or budgets, maximizing the total criticality of compatible routes is a maximum-weight independent-set problem.

Retained-coordinate cost. To account for lane demand, we penalize the additional coordinates required by the selected routes. For an independent set $I$ in the open stage $s$, we maximize

subject to separate budgets on retained rows and columns. Here, $g(p)$ is the gate implemented by route $p$, and $\ell_s(I)$ counts the additional row and column coordinates that $I$ requires compaction to retain, beyond the data-site coordinates and those already retained in stage $s$. Rows and columns count separately, and a coordinate shared by several routes is counted only once. Required coordinates come from route-segment endpoints and turns, and consumed magic-state tiles. The nonnegative weight $\lambda$ encourages selected routes

to reuse coordinates within a step and across successive steps of the stage. The objective thus extends criticality-weighted independent-set selection with costs for retained coordinates and lane budgets. Our router uses branch and bound to search for a compatible set of candidate routes that maximizes the score in Equation (7) while respecting the row and column budgets.

In Figure 9, candidates A, B, and C have criticalities 4, 2, and 4. A conflicts with B, while C is compatible with both. All three reuse retained coordinates, so the lane penalty is zero. We select A and C, with total criticality 8, rather than B and C, with total criticality 6, and defer B to a later step.

Qubit Placement

Placement assigns qubits and orientations to sites in the chosen virtual floorplan, anticipating contention and routing-space demand.

Initial placement. After selecting the shape, we place frequently interacting qubits near one another using spectral initialization. We construct a weighted qubit-interaction graph in which each edge counts the CX operations between its qubits. A uniform weight of $10^{-3}$ between distinct qubits connects otherwise disconnected components. The second eigenvector of the graph Laplacian, the Fiedler vector, orders qubits into groups of at most $w$ sites, one per virtual row. Within each row, the third eigenvector orders qubits into columns [20, 34]. Figure 10 illustrates this assignment.

Placement refinement. We refine the site assignment and qubit orientations using simulated annealing [74]. Let $\widehat{\chi}(\pi)$, $\widehat{\ell}(\pi)$, and $\widehat{L}(\pi)$ estimate route overlaps, retained routing lines, and path length, respectively. We minimize the estimated placement cost

The weights balance routing contention, retained routing space, and path length. Overlaps can delay gates, while scattered paths keep more rows and columns from being removed.

For each gate, a geometric proxy connects its endpoint sides through nearby lanes, using row-end magic for T. These paths ignore occupancy and need not be legal routes. For each dependency group, the retained-line estimate counts distinct row and column coordinates used by proxy endpoints, turns, and magic-state tiles, excluding data-site coordinates, then sums these counts across groups. For the overlap estimate, each tile records its most recent route within a dependency group, and a new route counts each encountered previous owner once. This scan can miss some pairwise overlaps when several routes share a tile.

The search uses two types of compile-time proposals:

• Site reassignment (Figure 11a–Figure 11b). Select a qubit and a destination site, swapping occupants if the site is occupied or moving the qubit if it is empty. In the example, $q_0$ and $q_5$ exchange sites, allowing $g_1$ and $g_2$ to share the upper lane without overlapping. With orientations fixed, the whole-circuit line estimate falls from 13 to 12 and path length from 29 to 28, with no overlaps.

• Orientation flip (Figure 11c–Figure 11d). Keep the site fixed and exchange the qubit’s Z and X boundary directions. Flipping target $q_1$ lets $(q_0, q_1)$ use a straight route in the upper lane, shortening it from four tiles to two and requiring one additional retained coordinate rather than two. A flip may make other interactions more expensive, so its score includes every affected dependency group.

By default, 20% of proposals flip orientations and 80% reassign sites. Annealing accepts improvements and occasionally accepts higher costs to escape local minima. Larger cost increases and geometric cooling make these uphill moves less likely. Our method compiles the chosen floorplan once, and the final qubit assignment and orientations remain fixed throughout execution.

Evaluation

We evaluate how demand-driven routing-space allocation affects space–time volume, compilation time, and routing-space utilization. After describing the experimental setup (§ 6.1), we compare compilation time with the baselines (§ 6.2 and § 6.3), then analyze the area–time tradeoff behind the volume savings (§ 6.4). A cumulative ablation examines the contributions of the compiler components (§ 6.5), and a sensitivity study examines the effects of cost weights and placement effort (§ 6.6).

Experimental Setup

We perform experiments on 60 circuits from different application families, as summarized in Table 1. The suite includes arithmetic circuits, quantum Fourier transforms and phase estimation, QAOA, oracles, and eight random stress circuits. These circuits vary in qubit count, CX and T gate count, dependency depth, T-gate share, and interaction structure, from nearest-neighbour chains to all-to-all communication. We run every compiler, our method, its solver controls, and the baselines, on the same AMD EPYC 9654 compute nodes, one CPU thread per compilation.

Table 1. The 60 benchmark circuits by family, with circuit counts and ranges of qubit count $n$, CX and T gate count $|C|$, and dependency depth $D$ (longest TDG chain in gates). The T share is the fraction of counted gates that are T gates.

family	#	$n$	$|C|$	$D$	T share	interaction
Arithmetic	28	5–192	50–53,437	24–2,314	33–64%	all-to-all
QFT, QPE	5	4–18	93–1,335	58–443	65–87%	T-heavy
QAOA	4	12–24	132–332	44–89	40–45%	graph
Random dense	4	8–32	150–600	43	33%	all-to-all
Random sparse	4	8–32	160–640	40	0%	disjoint groups
Oracles [3, 17]	7	8–30	7–39	7–29	0%	sparse, serial
Chains, FTCB kernels [38]	8	4–200	121–34,691	87–19,345	0–91%	nearest-neighbour

We compare our method with the following baselines:

• DasCOT [71] uses the same tile-step volume definition as our method, although its endpoint and magic-delivery rules differ.

• TopoLS [88] measures volume in tile-by-$d$-round cubes, where $d$ is the code distance; one CX step of our method spans two such cubes in time.

• FLASQ [48] provides an analytical resource estimate in blocks without constructing routes. We use Qualtran’s implementation with row-major square placement and choose the device size to minimize volume.

Moreover, we compare with Grid Search, which exhaustively enumerates the following hyperparameters for each $n$-qubit circuit:

• Virtual layout shape: $(h, w)$.

• Extra-row budget: $\Delta_H$.

• Extra-column budget: $\Delta_W$.

Grid Search selects the smallest verified volume after routing, compaction, and walks, holding the placement and routing algorithms and other settings fixed. Our method instead uses the demand-based heuristic in § 5.1 to predict one shape. Grid Search measures the benefit of exhaustive parameter selection within this family, rather than a global optimum.

For the main volume and ablation comparisons, we use one completed run per circuit for our method and its solver controls, with random seed 0. We report geometric means across circuits, with standard errors computed in log space.

Space–Time Volume Comparison

Figure 12 compares space–time volume across circuit families, normalized to DasCot. Although the improvement varies across families, our method achieves lower geometric-mean volume in every family and improves most individual applications. In geometric mean, our method reduces volume by 55.6% relative to DasCot and reports 61.9% lower numerical volume than TopoLS under their respective cost models (§ 6.1). These results support allocating routing space according to circuit demand.

Our method also reports numerical volumes close to FLASQ’s analytical estimates. However, FLASQ only estimates resources without constructing routes, whereas Our method produces an explicit tile-level program with routes and modeled movements under the architecture model in § 4. This distinction is important when interpreting the comparison: numerically similar volumes under different cost models do not establish equivalent physical resource requirements.

Grid Search measures the volume gap between our heuristic’s configuration and the best shape and lane budgets within the searched family, using the same placement and routing algorithms. Across the 48 applications with completed searches, our method’s volume is only 12.4% higher in geometric mean. Grid Search obtains this improvement through repeated compilation across shapes and lane budgets.

As the motivating example in § 2 illustrates, volume reductions over DasCot could also come from removing unused lanes or adopting a compact static layout.

To isolate the gains from on-demand layouts and the dynamic architecture, Table 2 compares the four configurations introduced in § 2: A Static (DasCot), B Static (Das-Cot Compacted), C Static (on-demand), and D Ours. We select 10 representative benchmarks from different families and report their chip dimensions, area, execution steps, and volume. Bold marks the lowest area, step count, and volume in each row, including ties.

circuit	$n$	gates	A Static (DasCot) chip	area	steps	volume	B Static (DasCot Compacted) chip	area	steps	volume	C Static (on-demand) chip	area	steps	volume	D Ours chip	area	steps	volume
clifford-16q-cx75	16	39	$11 \times11$	121	14	1,694	$9 \times9$	81	14	1,134	$7 \times8$	56	14	784	$7 \times7$	49	17	833
barenco-tof-5	9	156	$9 \times9$	81	110	8,910	$9 \times9$	81	110	8,910	$3 \times15$	45	110	4,950	$2 \times15$	30	111	3,330
rc-adder-6	14	177	$11 \times11$	121	107	12,947	$11 \times11$	121	107	12,947	$7 \times10$	70	107	7,490	$5 \times10$	50	107	5,350
qaoa-3reg-24	24	264	$13 \times13$	169	74	12,506	$13 \times13$	169	74	12,506	$9 \times12$	108	74	7,992	$7 \times12$	84	74	6,216
qaoa-er-16	16	332	$11 \times11$	121	89	10,769	$11 \times11$	121	89	10,769	$9 \times10$	90	90	8,100	$7 \times9$	63	109	6,867
ftcb-adder-28q	28	363	$15 \times15$	225	161	36,225	$15 \times15$	225	161	36,225	$7 \times16$	112	176	19,712	$5 \times16$	80	209	16,720
qcla-mod-7	26	779	$15 \times15$	225	200	45,000	$15 \times15$	225	200	45,000	$11 \times12$	132	201	26,532	$8 \times12$	96	206	19,776
gf2e8-mult	24	853	$13 \times13$	169	248	41,912	$13 \times13$	169	248	41,912	$7 \times14$	98	292	28,616	$5 \times14$	70	334	23,380
adder-8	24	1,012	$13 \times13$	169	259	43,771	$13 \times13$	169	259	43,771	$9 \times12$	108	259	27,972	$7 \times12$	84	267	22,428
qft-16	16	1,311	$11 \times11$	121	282	34,122	$11 \times11$	121	282	34,122	$9 \times10$	90	282	25,380	$7 \times9$	63	340	21,420
Geomean ratio	–	1.00	1.00	1.00	–	0.96	1.00	0.96	–	0.60	1.03	0.61	–	0.44	1.13	0.49

These results confirm the benefits of two mechanisms introduced by our method:

• On-demand layouts. Comparing A with B shows that only one program benefits from removing unused lanes, whereas comparing A with C shows that all benchmarks benefit from an on-demand layout. Post-processing a conservative layout cannot recover the same savings

because lanes rarely remain unused throughout the entire execution.

• Dynamic layouts. Compared with C, D uses less area for all of the 10 benchmarks. Since the only difference here is that C uses a single stage while D allows different stages to have different layouts, this shows how the dynamic architecture enables more aggressive lane reuse within stages. Although our method has the highest step count overall, its area savings outweigh the additional steps, yielding the lowest space–time volume overall.

Compile Time Comparison

In addition to reducing space–time volume, our method is, to the best of our knowledge, the fastest lattice-surgery compiler. As discussed in § 1, fast compilation provides timely feedback to guide circuit synthesis.

Figure 13 compares compilation time on application circuits that DasCot completes within one hour. We exclude very small circuits because their timings are more sensitive to measurement noise. The compilers run on the same machines using the experimental setup in § 6.1. Our method has substantially lower geometric-mean compilation time than either DasCot or TopoLS. The fitted trends also show more gradual growth with gate count for our method than for DasCot over the evaluated range.

These speedups mainly stem from the heuristics in § 5, which limit search effort at each stage. Whereas TopoLS uses Monte Carlo tree search for placement, we use simulated annealing for faster convergence with a controllable search budget. Whereas DasCot uses breadth-first search to find shortest routing paths, we assign one deterministic route to each interaction. We also select the floorplan using a proxy model instead of grid search. Together, these choices make our method 75.5× faster than DasCot and 2,240× faster than TopoLS in geometric mean.

The implementation also exploits graph sparsity: readiness updates follow dependency edges, and placement moves rescore only the layers they affect. Further implementation details are available in our open-source tool.

Breakdown and Utilization Analysis

To understand the sources of volume reduction, Figure 14 separates space–time volume into data-qubit tiles (■), magic-state tiles (■), routed free tiles (■), and idle free tiles (■), relative to DasCot. Our method reduces the idle routing-space contribution by sharing lanes and adjusting physical spacing. Within each program, routing-space utilization is the routed-free contribution (■) divided by the sum of routed-free and idle-free contributions (■ + ■). Geometric-mean utilization increases from 9.5% for DasCot to 28.0% for our method, an improvement of 18.5%.

The routed-free contribution increases in most families even as total volume decreases. This illustrates why minimizing path length alone is insufficient: a longer route can be worthwhile when it allows interactions to use a smaller shared layout. By accounting for both concurrency and the coordinates retained after compaction, the router can make this tradeoff rather than optimizing wire length in isolation.

Ablation Study

The preceding comparisons show the strengths of our method and its dynamic architecture. Realizing these benefits requires a specialized compiler. Figure 15 examines each compiler component’s contribution through a cumulative ablation that adds the methods introduced in Section 5:

• Vanilla: Execute one gate per step.

• + Dependency: Add dependency-aware scheduling (Section 3.1).

• + Routing: Add criticality-driven routing (Section 5.2) on the fixed grid, without compaction or walks.

• + Spacing: Add on-demand spacing (Section 5.1).

• + Placement: Add placement on a square Standard layout (Section 5.3).

• + Layout: Add layout selection (Section 5.1), yielding our method.

• Grid Search: Exhaustively select the shape and lane budgets with the placement and routing algorithms held fixed.

Each addition from + Dependency through + Layout retains the preceding components. The successive reductions show the benefits of scheduling concurrent gates, placing qubits to reduce contention, and matching the floorplan to circuit demand.

Among these additions, routing alone provides a smaller improvement on the fixed grid. Although route selection accounts for retained coordinates, reducing their number cannot shrink the charged area until compaction is enabled. Adding on-demand spacing converts this reduction in retained space into a smaller physical layout. This illustrates

the coupling between routing and compaction: routing determines which coordinates are needed, and compaction turns that choice into area savings.

Exhaustive configuration selection explores further volume reductions by repeatedly invoking placement and routing across candidate shapes and lane budgets. Predicting a single configuration avoids these repeated compilations, at the cost of potentially missing a better configuration.

Sensitivity Study

Although effective, heuristics often require hyperparameter tuning. Tuning each benchmark separately or repeatedly trying more random seeds can erode the advantage over exhaustive search. To assess robustness, we study sensitivity to the following parameters:

• Collision weight $w_{\chi}$ (Section 5.3): penalty for estimated route overlaps.

• Lane penalty $\lambda$ (Section 5.2): cost of additionally retained coordinates.

• Placement effort $\eta$ (Section 5.3): a cap of $\eta n$ annealing proposals.

• Lane budgets $\Delta_H, \Delta_W$ (Section 5.1): extra retained rows and columns, varied together.

We vary each parameter in turn, sweeping the two lane budgets together and keeping the other parameters at their default settings. Each experiment recompiles the complete program, including compaction and modeled walks.

In the other experiments, we use $w_{\chi}=6$, $\lambda=4$, $\eta=100$, and $\Delta_H=\Delta_W=6$. Across the settings tested in Figure 16, the maximum absolute percentage change in geometric-mean volume relative to the default configuration is 49.6%.

Collision Weight. Removing the placement collision term increases geometric-mean volume in Figure 16a. Increasing its weight beyond the default provides a smaller additional benefit. Accounting for contention therefore matters more than fine-tuning the precise weight.

Lane Penalty. Geometric-mean volume changes little across the evaluated penalty settings, including when the penalty is disabled. The zoomed axis in Figure 16b makes these small aggregate changes visible. Individual circuits can be more sensitive, as indicated by the markers at the axis boundaries.

Placement Proposals. Figure 16c shows that refining the spectral initialization improves volume, but additional search beyond the default effort does not consistently improve the compiled program. Annealing optimizes a placement proxy rather than final routed volume, so more proposals do not guarantee a better result. The figure also evaluates DasCot’s annealer under the same proposal caps and on the same inputs, with all declared qubits placed and no time limit.

Case Study: Feedback to Circuit Synthesis

The preceding evaluation shows our method’s effectiveness and efficiency as a lattice-surgery compiler. As discussed in § 1, these compilers also provide feedback and technology-dependent insights to guide circuit synthesis.

We use GF($2^k$) multipliers to compare three classes of circuit optimizers and study their implications for lattice surgery on superconducting-qubit platforms. GraySynth [1] targets CX count, T-par [2] targets T depth, and FastTODD [82] targets T count. We compare the feedback from our method with that from DasCot.

Figure 17 shows the results for the 21-qubit multiplier. Both compilers account for tradeoffs between T and CX gates

and show similar trends when magic-state supply is unconstrained, our model for the T-cultivation setting [30]. In this regime, aggressive T-count optimization introduces substantial ancilla-qubit and CX overhead, so FastTODD consumes more volume than GraySynth, which targets only CX count.

An advantage of our method and its dynamic scheduling is that we can readily evaluate different assumptions about T-state supply. For example, modeling the $3 \times3 \times11$ distillation factories from LaSsy nth [79] requires only adding dependencies to the TDG based on their throughput. Under this supply constraint, T-count optimization becomes beneficial and outperforms optimization of CX count alone.

Future work could use our method as a reward model to guide synthesis at a finer granularity and search for better tradeoffs. Its efficiency and accuracy make it well suited to this role.

Related Work

LibLSQECC [59, 60, 84], DasCot [71], Ecmas+ [90], and resource-allocating compilers [73] map and schedule lattice surgery. TISCC generates physical circuits for surface-code patch operations on trapped-ion processors [61]. SAT-based synthesis and spacetime-routing compilers optimize three-dimensional realizations [7, 35, 36, 62, 79, 88]. SpiderLS applies full ZX reduction and lowers the resulting interactions to Pauli-product measurements before routing them with fixed data-patch positions [54]. TQEC lowers three-dimensional block graphs to physical Stim circuits [78], and Hao et al. integrate physical-circuit compilation and simulation to study algorithmic break-even [37]. Patchwork constructs physical measurement circuits on a prescribed layout with narrow corridors and partitions the merged patches in spacetime for parallel decoding [13]. Herzog et al. extend mapping and routing to other code substrates [42] and develop pipe diagrams for the color code [43]. Analytical resource estimators instead provide cost estimates without constructing routes [5, 39, 48].

Layout designs trade data density against space for concurrent routes. Litinski’s compact blocks [64], checkerboard placement [58], O3LS’s squeezed layout [89], SPARO’s expandable routing area [53], distillation-adaptive layouts [75], LAPBC [44], and Q-Spellbook [15] explore different arrangements of data and routing tiles. Unlike O3LS’s Pauli-product scheduling, our main flow’s compaction preserves a routed CX/T schedule and the endpoint orientations selected during placement. The extension in Section E applies stage compaction to multi-qubit Pauli operations. Dense storage [29, 56, 68], workload-specific floorplans [25], and multiprogramming [24] address how chip capacity is partitioned and reused. Braiding and its connection to lattice surgery [47, 50, 72], distillation [8, 18, 28, 51, 65], and circuit synthesis and instruction scheduling [6, 57, 83] optimize the operations performed on the chip. Alternative connectivity [66, 81], temporal protocols [12, 21], and fixed-layout scheduling [77] address complementary resource costs. Beverland et al. study edge-disjoint CX routing on shared space [4].

Related approaches adapt patch allocation and placement during execution. CircLS allocates each patch from first to last use [87], while RushHour reshapes a staircase corridor with patch slides to unblock ready gates [80]. Herzog et al. move logical qubits by teleportation during a CX, with a proof-of-concept compiler for the color code [41]. PureMagic dynamically shares ancilla patches between routing and magic-state cultivation [30, 45]. FlowRouter combines maximum-flow routing of Clifford layers in three-dimensional spacetime with runtime cultivation on idle patches and delay insertion when states are unavailable [49]. Walking surface-code constructions [70] and dynamic-code memory experiments [19] motivate patch movement. Our method forms stages during routing and compacts them, preserving gate grouping, all data qubits, and their order while changing spacing through modeled bulk walks. Classical layout compaction also preserves geometric constraints [63], while two-layer channel routing permits wires to cross on separate layers [86]. Our tile-disjoint paths cannot cross within a step, so area savings may incur serialization.

Conclusion

Our method combines a dynamic architecture with compaction-aware routing and demand-driven floorplanning. Across our application circuits, it reduces geometric-mean space-time volume by 55.6% and compiles $75.5 \times$ faster than DasCot.

Acknowledgments

The authors thank Dr. Daniel Tan for valuable discussion. H. Wang and J. Cong were supported by the National Science Foundation under Award Nos. 2533041 and OMA-2016245, the industrial partners of the Center for Domain-Specific Computing (https://cdsc.ucla.edu/partners/), and a gift from Google LLC. Z. Chen and Z. Zhang acknowledge support from the National Science Foundation under Award No. 2529338. J. Cong has financial interest in Google and IBM.

References

Local Resynthesis with LaSsynth

The compiler in § 5 optimizes routing space but realizes gates individually. Synthesizing a group of gates together may yield a shallower implementation. In this section, we introduce local resynthesis in two steps. We first extract small windows from the tile program for independent optimization. We then use LaSsynth [79] to search for the shallowest pipe diagram for each window’s Clifford computation. Fixed footprints and spatial ports let the search focus on depth.

Window Extraction. Ideally, we would apply exact SAT-based synthesis to the entire program, allowing optimizations to span all gate boundaries. However, the cost of exact synthesis makes this impractical at scale, so we restrict the search to small windows. For these experiments, we limit each window to 16 tiles, 4 steps, and 12 ports. These bounds keep each search small, at the cost of excluding optimizations that require a larger region.

Each window spans a rectangular tile region and contiguous steps within one fixed-mapping stage of § 4.1. We require the window to be closed: every route in that interval must lie entirely inside or outside the region. This condition lets us change the routes inside a window without disturbing routes outside it. Windows spanning the same steps form a slab and share no qubits, so their synthesized implementations can execute in parallel. A dynamic program chooses the slab boundaries, as illustrated for tof-3 in Figure 18b.

Window Resynthesis. We pass each extracted window to LaSsynth with fixed spatial port positions, allowing a replacement to reconnect to the surrounding program. For windows containing T gates, we represent each T merge as a magic-state input port, leaving only the Clifford skeleton for LaSsynth to resynthesize. The solver tests increasing depths starting at one layer, with a limit of 60 s per call. If it finds no shallower solution, we retain the original pipes, ensuring that resynthesis never increases the input program’s depth.

The deepest resynthesized window determines each slab’s estimated depth (Figure 18c). With the footprint fixed, fewer layers reduce the volume objective in § 4.2. Note that LaSsynth may introduce Hadamard walls and Y cubes, whose additional implementation costs are omitted from this estimate.

Local resynthesis cuts our method’s volume by 40% in geometric mean, placing every tabulated circuit below both baselines (Table 3). The benefit extends to nine Clifford-only circuits, whose geometric-mean volume falls from 710 to 459, also below both baselines. The gains depend on window coverage: fully covered circuits improve most, while wide steps in gf2e4-mult exceed the budget and remain unchanged. Longer searches cannot help these excluded steps, and no synthesis call times out. These savings require minutes of synthesis per circuit, compared with seconds for constructing the input tile program. We cache synthesis results for repeated windows, so runtime depends on the number of distinct windows and the cost of ruling out shallow depths. These searches could run in parallel, although measured sequentially here.

circuit	$n$	gates	Volume: DasCot	Volume: TopoLS	Volume: Ours	Volume: + LaSsynth	Compile time (s): DasCot	Compile time (s): TopoLS	Compile time (s): Ours	Compile time (s): + LaSsynth
barenco-tof-3	5	52	6,156	2,070	1,440	612	0.03	169	0.17	616
mod5-4	5	56	7,128	2,160	1,840	800	0.03	198	0.19	698
ftcb-qft-4q	4	93	5,684	1,971	1,920	944	7.95	344	0.20	233
mod-mult-55	9	97	7,614	5,670	3,120	2,310	2.17	386	0.84	466
barenco-tof-4	7	104	11,988	4,320	3,744	2,616	0.05	363	0.71	367
vbe-adder-3	10	128	17,424	5,796	5,616	3,600	5.31	496	1.17	423
qft-4	5	134	17,010	5,175	4,280	2,200	0.07	460	0.41	460
barenco-tof-5	9	156	17,820	8,757	6,496	3,724	0.06	618	1.31	488
rc-adder-6	14	177	25,894	10,854	11,520	8,360	19.5	831	2.35	438
csla-mux-3	15	191	16,456	10,692	7,200	5,350	13.0	982	3.04	446
gf2e4-mult	12	211	24,926	11,277	10,710	8,370	31.3	882	2.27	529
geomean			12,606	5,194	4,253	2,559	0.82	453	0.75	454

Hierarchical Compilation

The compiler in § 5 operates on a flattened gate list, repeating placement and routing work across calls to the same subroutine. Hierarchical representations, such as Qualtran bloqs [39], expose these repetitions and enable compilation reuse. Robertson et al. [73] recursively reuse compiled lattice-surgery objects as gates in larger compilations, but their objects have fixed dimensions and input/output interfaces. In our dynamic architecture, however, physical spacing must adapt to the routing demand of overlapping calls. Reusing fixed physical layouts would therefore limit the flexibility of stage-level compaction.

To enable hierarchical reuse without sacrificing dynamic routing-space allocation, we separate cell compilation from physical compaction. We first construct a shared virtual floorplan that fixes qubit assignments and preserves row and column orders across cells. Each distinct cell is then routed once on this floorplan, and parent schedules are composed bottom-up from cached implementations, resolving routing conflicts as needed. Only at the root do we form stages and compact them according to their combined routing demand. Walks connect successive stages, allowing physical spacing to vary while reusing the compiled cells. This reuse could also amortize local resynthesis, as discussed in Section A.

Cells. We lower each Qualtran benchmark to CX and T gates while preserving its subroutine call tree. Each leaf contains primitive gates, while a parent consists of child calls and possibly gates executed directly at that level (direct gate runs). We cache the routed schedule of each distinct leaf, direct gate run, and parent for reuse across repeated calls. Since routing depends on qubit placement, two cells can share a cached implementation only if they perform the same operations on the same global qubits. For example, B and B′ in Figure 19b implement the same logic on different qubits and therefore require separate implementations. Reusing a parent additionally requires the same ordered sequence of child calls and direct gate runs.

Shared Floorplan. Because cached cells include routing paths, reusing them requires compatible qubit placements. If each cell were placed independently, the same qubits could have different row or column orders across cells. Such placements cannot be reconciled by the walks in § 4, which adjust qubit spacing but preserve their relative order. We therefore construct a single virtual floorplan for the entire program and compile all cells against this shared placement. This ensures a consistent spatial arrangement for composing their routed schedules, while allowing physical spacing to vary during stage compaction.

To construct the shared floorplan efficiently, we run the placer of § 5.3 once using dependency layers from distinct leaf cells. Each layer is weighted by its number of invocations in the expanded call tree, preserving the relative frequency of interactions without repeatedly processing identical cells. By considering gates only at the leaves, we also avoid double-counting operations represented by their ancestors. However, this approach introduces two limitations.

First, the shared placement restricts cell-level optimization: even qubits unused by a cell remain routing obstacles, as illustrated by cell A in Figure 19b. Second, placement considers each leaf’s dependency layers independently and therefore only approximates contention between overlapping calls.

Bottom-Up Compilation. Given the shared floorplan, we compile the call tree from leaves to root, without a cell-size cutoff (Figure 19a). We first route each distinct leaf or direct gate run once, caching its per-step schedule and routes (Figure 19b). We then construct each parent by composing its cached children and direct runs, and cache the resulting schedule for future reuse. For example, repeated CModAddK calls reuse both their descendants and composed schedules, as do the two calls of B in Figure 19c.

Although cells share a floorplan, their routes may conflict when multiple calls overlap in time. To compose their schedules, we process ready child steps in call order, respecting dependencies and tile availability while preserving each call’s internal step order and gate grouping. When routes conflict, we first attempt to reroute them using the candidate search of Section 5.2, followed by a general shortest-path search. If neither succeeds, the conflicting step is delayed. A call releases each qubit after its last use, allowing subsequent calls to begin before the earlier call finishes (Figure 19c).

Hierarchical compilation achieves a 2.45× geometric-mean speedup at the cost of a 12.7% increase in space–time volume (Table 4). The speedup comes from two sources: reusing compiled cells and reducing placement effort. Reuse provides the largest gains for modexp-3, modmul-4, and qrom-6, which contain many repeated subroutines, and also benefits the smaller hubbard-2 circuit. Even add-16, where all cells are distinct, compiles faster because leaf-local placement is cheaper than placement on the full dependency graph.

circuit	$n$	gates	calls	cells	Volume ratio	Time (s) Flat	Hier.
modexp-3	22	5,040	1,372	170	1.11	23.19	3.10
modmul-4	24	2,904	752	162	1.05	13.74	2.49
gf2inv-4	32	775	65	63	1.16	3.15	2.52
modadd-8	34	531	132	131	1.10	2.18	1.80
add-16	47	252	61	61	0.99	1.20	0.98
hubbard-2	19	336	91	51	1.27	1.06	0.49
qrom-6	17	921	239	55	1.04	2.81	0.57
gf2mul-8	24	981	66	66	1.34	4.69	3.00
geomean					1.13	3.72	1.52

The volume overhead also has two sources. First, cached schedules preserve the gate groupings within each cell. During composition, steps can be rerouted or delayed, but gates cannot be regrouped to better accommodate overlapping calls. Second, leaf-local placement does not capture routing contention between calls, potentially increasing their combined routing demand. For gf2mul-8, using the flattened circuit’s placement reduces the volume overhead from 34% to 18%, but brings compilation time close to the flat baseline. This illustrates the tradeoff between compilation efficiency and global optimization quality.

Magic-State Supply

Each $T/T^\dagger$ gate requires a fresh magic state in the routing model of § 3. While the volume comparisons in § 6.2 assume states are available on demand, finite supply can introduce additional resource costs and execution delays. We consider two supply mechanisms: distillation in external factories and in-place cultivation, illustrated in Figure 20.

Magic-State Distillation. Distillation produces magic states in dedicated factories, requiring additional chip area and delivery routes. We model $F$ factories outside the $H \times W$ computation grid, each occupying $H_f \times W_f$ tiles and producing one state every $P$ units of $d$ QEC rounds. Together, the factories occupy $F H_f W_f$ tiles and provide an aggregate production rate of $F/P$ states per time unit. Since each routed step spans two such units, the cumulative number of states produced by the start of step $t$ is

This supply constraint may delay $T/T^\dagger$ gates until sufficient states have been produced. Our aggregate model assumes no initial stock, omits factory startup time, and does not credit production during inserted walks.

To deliver these states, we allocate concentric routing rings around the $H \times W$ computation grid, expanding its dimensions to $(H+2F)\times(W+2F)$. Each factory connects to magic-state tiles at row ends through a dedicated ring, with ports arranged to avoid crossing delivery paths (Figure 20a). The delivery pass detects route conflicts but does not resolve them or account for transport delays. Including both the delivery rings and factory footprints, the total space–time volume is

where $T_{\mathrm{exec}}$ counts execution steps, including walks.

Magic-State Cultivation. Unlike distillation, cultivation [30] prepares magic states directly in the designated magic-state tiles, eliminating the need for external factories and delivery routes (Figure 20b). However, preparation is stochastic because unsuccessful postselection requires a restart. We therefore adapt routing to sampled state arrival times: a $T/T^\dagger$ gate waits until a state becomes available, while ready CX gates may proceed independently. Once prepared, a state remains at its tile until consumed, after which a new cultivation attempt begins.

Mapping Initialization and Refinement

The placer in § 5.3 initializes qubit positions using spectral placement and refines them through simulated annealing. Since placement affects both routing contention and the space retained after compaction, we investigate how sensitive the final volume is to the initial assignment and the amount of refinement. Extending the placement-effort study in § 6.6, we compare seven initialization methods across different annealing budgets. As required by § 4.1, the resulting virtual placement remains fixed throughout execution.

Initial Placements. We compare spectral and random initialization with five classical VLSI placement methods adapted to our virtual site array. Spectral initialization uses the qubit-interaction graph, while random initialization assigns qubits uniformly to distinct sites. Among the VLSI methods, GORDIAN minimizes quadratic wirelength with region-centroid constraints and recursive bisection [55]. GORDIAN-L modifies its objective to approximate linear wirelength [76]. Min-cut recursively partitions the array using balanced graph cuts [11]. APlace optimizes smooth wirelength and density penalties [52], while mPL uses multilevel coarsening and refinement of the interaction graph [14]. We implement the core formulations of these methods for comparison.

To isolate the effects of placement, all methods use the same demand-predicted array shape, fixed qubit orientations, and identical routing, compaction, walk, and on-demand magic-state supply models. We independently verify each compiled program and average results over three random seeds per circuit, except for deterministic initializations without annealing, which require only one run. Each annealing budget uses a complete cooling schedule.

As shown in Table 5, refinement with 100$n$ proposals brings the geometric-mean volumes of all seven initializers within 1% of the annealed spectral baseline. Most improvements occur early: just 30$n$ proposals reduce the initial

Initial placement	No SA	With SA
Spectral	+5.61	0.00 ± 0.00
Random	+12.08	+0.28 ± 0.51
GORDIAN	+1.96	+0.08 ± 0.59
GORDIAN-L	+1.87	−0.27 ± 0.55
Min-cut	+3.18	−0.17 ± 0.54
APlace	+2.87	−0.44 ± 0.52
mPL	+3.16	+0.92 ± 0.52

volume penalties of 2.0%–12.6% to 0.2%–1.2% (Figure 21). Increasing the budget from 100$n$ to 200$n$ further reduces spectral volume by only 0.34%. These results suggest that moderate annealing largely eliminates differences between initializers, with diminishing returns from additional refinement.

Pauli-Based Computation

The execution model in § 3.1 routes each CX and T gate individually. Pauli-based computation (PBC) instead absorbs Clifford operations into Pauli rotations associated with T gates [10, 64]. This can eliminate routed Clifford operations, but the resulting rotations may involve multiple data qubits, increasing routing demand. To explore this tradeoff, we extend our compiler to support multi-qubit Pauli rotations through merges connecting multiple patch boundaries. We then study how limiting the number of data qubits per merge affects space–time volume.

Capacity-Limited Transformation. PBC pushes Clifford gates to the end of the circuit, transforming each T gate into a Pauli rotation $R_P = e^{-i\pi P/8}$, followed by a final Clifford circuit [10, 64]. Specifically, a T gate on qubit $q$ preceded by Clifford gates $C$ becomes a rotation about $P = C^{\dagger} Z_q C$, where $P$ is a signed tensor product of I, X, Y, and Z. For example, Figure 22a shows how four CX gates and one T gate can be replaced by a single rotation about $Z_0 Z_1 Z_2$. Although this

transformation eliminates routed Clifford gates, the resulting rotations may involve more qubits and require more routing space.

To control this tradeoff, we represent each multi-qubit rotation as a routing net and introduce a net capacity $\sigma$, which limits the number of data qubits connected by a single net. When absorbing additional Clifford gates would produce a rotation exceeding this capacity, we instead route the deferred CX gates and restart the transformation with an empty Clifford part. Thus, $\sigma= 1$ restricts rotations to single qubits, while $\sigma= \infty$ allows unrestricted Clifford absorption.

For circuits with measured outputs, the final Clifford circuit can also be absorbed into the Z-basis measurements [64], producing multi-qubit Pauli readouts that require routing but no magic states. We apply the same capacity constraint to these readouts. If a readout exceeds $\sigma$, we execute the final Clifford circuit instead.

Patches and Routing. To support PBC, we generalize the two-endpoint routes of § 5.2 to multi-pin nets, where each pin represents a required patch-boundary contact. An X or Z Pauli factor contributes the corresponding boundary contact, while a Y factor requires both but counts as only one data qubit toward the net capacity $\sigma$. To expose these contacts, we represent each logical-qubit patch using two vertically adjacent tiles [64], with X and Z contacts on the upper and lower tiles, respectively (Figure 22b).

We route each net as a connected tree spanning all required boundary contacts and, for Pauli rotations, a magic-state tile. Candidate trees consist of a horizontal trunk along a routing lane with vertical branches to the contacts, as illustrated in Figure 23. If no candidate is available, we fall back to a greedy shortest-path search. Route selection retains the criticality scores and lane costs of § 5.2, together with the stage budgets of § 5.1. To prevent conflicting operations, each merge reserves both contacts of every participating qubit for its execution step. We also preserve the order of rotations with anticommuting Pauli axes.

Finally, stage compaction extends the retained-coordinate rule of § 5.2 to include tree branch junctions, preserving connectivity between all pins. Between stages, the walks

of § 4.1 move both tiles of each patch together. An independent checker validates the resulting program.

We compare the circuit flow of § 5 against PBC with net capacities $\sigma\in\{1, 2, 3, 4, 8, \infty\}$ on 29 circuits containing 5–36 qubits. For each configuration, we use seed 0 and select the lowest-volume result among the three smallest-area shapes and the most square shape. As in § 6, we initially assume on-demand magic-state supply, with a fresh state available at every magic-state tile at the end of each patch row in every step. We measure tile-step volume using § 4.2, including walks and counting one step per routed CX, Pauli rotation, or multi-qubit readout. The model omits magic-state preparation, single-qubit Clifford costs, and classical-control delays.

Under on-demand magic-state supply, PBC reduces execution steps at the cost of larger chip area. For $\sigma\ge3$, the step savings outweigh the area overhead in geometric mean (Figure 24a). At $\sigma= \infty$, PBC reduces geometric-mean volume by 32.4%, improving all tested Toffoli constructions and finite-field multipliers, as well as 9 of 11 adder and modular-arithmetic circuits (Figure 25a). These circuits contain roughly one T gate per CX, whereas QFT and QPE contain approximately four. Clifford absorption therefore eliminates a larger fraction of routed operations in the former circuits without changing the T count. In contrast, QFT and QPE incur 53%–119% higher volume despite shorter execution schedules, because their wider Pauli rotations require more routing space. Even among arithmetic circuits, qcla-adder-10 and csum-mux-9 exhibit higher volume at every capacity.

The benefits of PBC diminish when magic-state production limits execution. To evaluate this regime, we repeat the sweep with two $3 \times3 \times11$ distillation factories from Section C. Since PBC preserves the T count, both flows face the same total magic-state demand and production throughput. Consequently, PBC’s reduced routing depth provides little execution-time benefit: its step count remains between 1.00 and 1.02 times that of the circuit flow across all capacities (Figure 24b). Meanwhile, its larger chip footprint increases geometric-mean volume by 9.2%–20.7% (Figure 25b). These results indicate that PBC is most beneficial when routing, rather than magic-state production, limits execution.