Pith. sign in

REVIEW 3 major objections 8 minor 91 references

Efficient LLM-Generated Shuttling Compilers for Complex Trapped-Ion Architectures

T0 review · 3 major / 8 minor · reviewed 2026-07-31 · grok-4.5

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read An unmodified frontier LLM can write full trapped-ion shuttling compilers that often beat hand-crafted ones and cut build time from months to days.

desk verdict Real systems result on LLM-written shuttling compilers, but the headline “beats hand-crafted” wins partly ride on dynamic gate ordering the baselines never got. read the letter →

arxiv 2607.24714 v1 pith:F4ODHAIT submitted 2026-07-27 quant-ph cs.AIcs.ET

Fabian Kreppel , Reza Salkhordeh , Ferdinand Schmidt-Kaler , André Brinkmann This is my paper
classification quant-phcs.AIcs.ET
keywords trapped-ionquantumcomputingshuttlingcompilerQCCDlargelanguagemodelscodegenerationiontransportjunctionarchitecturescircuitcompilation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Trapped-ion machines move ions around a chip to run gates, and each new trap layout usually needs months of expert work on a custom shuttling compiler. This paper shows that a single frontier language model, given a detailed written specification and seeded with prior-stage code, can emit and refine the entire Python compiler for three increasingly general layouts: a linear segmented trap, a branched trap with junctions and stacks, and a broad class of connected trap graphs. On shared circuit benchmarks the generated compilers cut shuttling timesteps by up to 76% on the linear case and up to 39% on the branched case versus published hand-crafted baselines, largely by choosing the next ready gate while routing rather than following a fixed upstream order. Across many connectivities, dense junction-rich graphs need far fewer moves than corridor-like ones—sometimes an order of magnitude. A full rerun with a second frontier model reproduces the qualitative picture. The practical claim is that new architectures no longer need months of hand engineering for a competitive compiler.

What carries the argument

Chained specification-driven code generation: each compiler is written as a single Python file from a prompt that fixes the algorithm and interfaces; later compilers are seeded with the previous optimized code plus a delta specification, then refined by follow-up prompts that target timesteps, compile time, and memory, with schedules checked by immutable validators.

What would settle it

Re-run the same LLM-generated and hand-crafted compilers on identical circuits while forcing both sides to use the same gate order (or both to choose from the ready set); if the timestep advantage largely disappears, the central superiority claim about shuttling quality does not hold as stated.

Watch

Extended reading notes

Core claim

An unmodified frontier LLM, prompted with complete algorithmic specifications and acceptance tests, can generate validator-checked Python shuttling compilers for linear, branched, and general connected trapped-ion architectures that are competitive with—and often beat—state-of-the-art hand-crafted compilers on the same circuits, reducing development time from several months to a few days.

Load-bearing premise

The headline wins fairly credit the generated programs as better shuttling engines, even though they pick each next gate from the ready set during routing while the hand-crafted baselines must follow a fixed upstream gate order, and even though every first prompt already spells out a full algorithm taken from those baselines.

Editorial extensions

If this is right

  • Building a specialist compiler for each new trap layout becomes cheap enough to prefer over one general compiler when performance matters.
  • Architecture connectivity is a first-order design knob: dense junction-rich graphs can cut shuttling by up to ~90% versus sparse corridors under the same compiler.
  • Relaxing the boundary between circuit compilation and shuttling—letting the shuttler pick ready gates—systematically shortens schedules versus fixed program order.
  • The same prompt-and-seed pipeline can be repeated for multi-gate-zone devices and richer ion-crystal models once those specifications are written.
  • A second frontier model reproducing the qualitative results suggests the method is not tied to one vendor model.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Most of the reported edge may be joint scheduling-plus-routing policy rather than pure ion-path quality; fair ablations on gate order would re-rank how much is ‘compiler generation’ versus ‘relaxed compilation boundary’.
  • Because prompts encode complete algorithms from existing hand-crafted compilers, the method is closer to high-fidelity code synthesis of expert designs than to open-ended algorithm discovery.
  • If multi-gate-segment and free separate/merge/swap extensions work the same way, hardware groups could treat compiler retargeting as a days-long prompt cycle whenever the trap graph changes.
  • The large spread across trap graphs implies co-design of connectivity and compiler may dominate pure compiler tuning for near-term QCCD machines.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 8 minor

Summary. The manuscript reports the first study in which an unmodified frontier LLM (Claude Opus 4.7, replicated with Claude Fable 5) writes the complete Python code of trapped-ion shuttling compilers from written specifications, in a chain of increasing generality: (i) linear segmented trap, (ii) branched trap with junctions and LIFO stacks, (iii) general connected trap graphs. Each compiler is seeded from its predecessor and refined by follow-up optimization prompts; schedules are checked by fixed validators the LLM may not modify. Benchmarked against two hand-crafted state-of-the-art baselines on a 153-circuit library and five scalable families (up to 50 qubits), the optimized generated compilers reduce shuttling timesteps by up to 76% (linear) and 39% (branched), with median reduction factors ~1.2; the general compiler additionally exposes a first-order connectivity effect (up to ~10× between dense junction-rich and corridor-like layouts). The authors are unusually transparent about limitations: the scheduling-boundary asymmetry (generated compilers choose gates from the ready set; baselines route fixed program order), the branched QAOA case where the baseline wins, the translation-only controlled slice (§V.D, Fig. 5) where the generated compiler scales worse, the rotor-conveyor's incomplete generality, and large compile-time overheads from candidate-placement search. The central claim is methodological: validator-checked LLM code generation cuts per-architecture compiler effort "

Significance. If the results hold, this is a useful and timely demonstration for the trapped-ion compilation community: per-architecture compiler engineering is a real bottleneck, and showing that a specification-plus-seed workflow with validator-checked output produces competitive compilers in days is of practical interest, as is the finding that two independent frontier models reproduce the qualitative picture. Strengths that deserve explicit credit: complete prompts reproduced in the appendices; fixed, uneditable validators checking physical legality of every reported schedule; shared benchmark suites with published baselines; reporting of both suite totals and median reduction factors; honest negative results (the translation-only comparison in Fig. 5, branched QAOA losses, incomplete generality of the rotor-conveyor, compile-time overheads of 100–1000×); and a genuinely novel byproduct in the architecture-suitability analysis. The caveats are about what the numbers demonstrate (joint schedule+route advantage rather than pure routing superiority; LLM as implementer of a supplied algorithm rather than algorithm inventor), not about their internal validity.

major comments (3)
  1. [§III.B, §IV.D, §V.D, Fig. 5, §VIII] The head-to-head wins confound routing quality with gate-ordering freedom. Generated compilers pick each next gate from the ready set during routing; both baselines route a fixed upstream program order (§IV.D, §V.D), and §VIII concedes the advantage 'comes largely' from this. The paper's own controlled slice confirms the risk: at h=1,d=1 (zero swaps, matched sep/merge counts) the comparison reduces to translations, and the generated compiler needs ~29% fewer at 3 qubits but ~25% MORE at 15–16, with the fit crossing below 1 at ~11 qubits (Fig. 5). Request: run the optimized compilers constrained to program order (a small change — the prompt's tie-break already prefers the earliest ready gate) to decompose ordering vs. routing gains, or calibrate the abstract/§VIII claims to 'joint gate-ordering+routing policies' rather than shuttling compilers per se.
  2. [Abstract; §III.A; §VIII] The abstract's 'without additional manual algorithmic engineering' is in tension with §III.A: every first prompt 'sets out a complete algorithm, based on the hand-crafted compilers' (refs. 11, 16), and preliminary tests without one failed to produce a working compiler. Appendix B in particular specifies routing methods, cost formulas, tie-break orders, fallback chains, and post-processing passes in full — that is the algorithmic engineering, transferred from months of prior hand-crafted work. The months→days claim is still meaningful for adapting to a new architecture, but the demonstrated capability is LLM-as-implementer/refiner of a given algorithm, not LLM-as-algorithm-designer. The abstract and §VIII should say so explicitly; one accurate sentence would suffice.
  3. [§III.B vs. §VI.D.c; Tabs. V–VII] The summary-metric policy is applied inconsistently. For compiler-vs-baseline comparisons, the median of per-circuit reduction factors is used because totals 'are dominated by the few largest circuits'; for the architecture comparison (Fig. 6) the same paper sums totals because 'the largest circuits... are where the choice... matters most.' Each choice favors the generated compilers in its context: on the branched scalable families the baseline wins suite totals in 4 of 5 families (Tab. VI: QAOA 723k vs 1,199k; QV, XEB, XEB_Sy likewise) while medians read 1.1–1.3. Please report both medians and suite totals for the compiler comparisons (including Tab. VII) and add a sentence reconciling why the two questions warrant different summaries.
minor comments (8)
  1. [Data Availability] Data availability is 'upon reasonable request.' For a code-generation study the generated compiler files, conversation logs, and benchmark outputs are the evidence; please deposit them (e.g., Zenodo). The full prompts in Appendices A–C are already a strength.
  2. [§V.C–D] §V.D reports compile-time overheads of hundreds-to-thousands times the baseline (up to 150 candidate placements vs. one deterministic placement), and §V.C notes tens-to-hundreds times from the park method alone. Since the title advertises 'Efficient,' a compact summary table of compile times per compiler and family would keep the claim properly scoped.
  3. [§VI.B (rotor-conveyor)] Given that completeness on general graphs is an acknowledged limitation, please quantify it: on how many acceptance/evaluation instances (of the ten architectures) does the bounded rotor-conveyor report failure despite free qubit vertices remaining? Even a coarse failure-rate sentence would let readers judge how broad 'a broad class' is in practice.
  4. [§IV.A, depth-weighting] 'τ ≈ total_dag_depth/3' — the ≈ is odd for a deterministic, reproducibility-critical heuristic. State the exact rule (rounding, floor, or float division) used in the generated code.
  5. [Fig. 5 caption] The caption would help readers by stating what the text establishes: at h=1, d=1 the generated compiler emits zero swaps and matches the baseline's separation/merge counts on all but one circuit, so the factor is decided by translations alone. Without this, the crossing of the fit below 1 at ~11 qubits is easy to misread.
  6. [§V.B, §VII.a] The per-iteration cost-driven method choice among swap/stack/park-the-endpoint (Appendix B, §6.2) is omitted by both emitted compilers and only partially recovered during optimization. Since this is the same deviation in both LLM runs, a short note on whether the follow-up prompts explicitly pointed at the omission (or the LLMs found it themselves) would clarify how much of the recovery is LLM-driven.
  7. [Tab. VII] Tab. VII: please also report compile-time statistics for the Fable 5 vs. Opus 4.7 comparison, since Fable 5 'optimizes more aggressively' and the search budgets differ across runs.
  8. [Throughout] Typos/formatting: several words run together in the PDF extraction (e.g., 'generalpurposelargelanguagemodel', 'aspecification', 'TrapGraph's'); reference 3 has a stray '901—-919'. Please proofread the final typeset.

Circularity Check

0 steps flagged · score 1.0 of 10

Empirical systems paper with external benchmarks; no derivation-by-construction circularity.

full rationale

This paper claims that frontier LLMs can emit full, validator-checked Python shuttling compilers from written specs that are competitive with hand-crafted baselines on shared circuit suites. That claim is evaluated by running generated code and baselines on fixed external circuits and counting legal timesteps; the validators check physical legality of schedules, not agreement with a fitted target. The prompts deliberately encode complete algorithms drawn from the authors’ prior hand-crafted compilers, and later stages are seeded with earlier generated code—this is methodological inheritance and engineering reuse, not a self-definitional loop in which a reported metric is forced by how an input was defined. There is no fitted parameter renamed as a prediction, no uniqueness theorem imported to forbid alternatives, and no ansatz smuggled in via citation as if it were a theorem. Concerns that the head-to-head wins partly reflect ready-set gate ordering (vs. fixed program order in the baselines) or that “without additional manual algorithmic engineering” overstates the role of the detailed algorithmic prompts are fairness and claim-accuracy issues, not circularity of a derivation chain. Score 1 only for ordinary self-citation of the seed baselines as prior art, which is not load-bearing for the measured results.

Assumptions & free parameters 3 free parameters · 5 assumptions · 2 invented entities

Load-bearing content is mostly standard trapped-ion QCCD operating assumptions plus an experimental protocol (prompted LLM coding with frozen validators). No physical constants are fitted. The main “axioms” are hardware model constraints and the methodological choice to fully specify algorithms in prompts. Invented entities are software artifacts (the three compilers), not new physical objects.

free parameters (3)
  • Depth-weighting τ ≈ total_DAG_depth / 3 in initial mapping = total_dag_depth/3
    Heuristic scale in the interaction-graph edge weights for placement; inherited from the specified default algorithm and can change pairing/placement quality.
  • Candidate-placement compile budgets / proxy scores (branched & general) = e.g. up to ~150 candidates mentioned; time budget derived from first candidate op count
    Deterministic caps on how many mappings are trial-compiled and the interaction×distance proxy used to rank them; directly trade schedule length vs compile time.
  • Architecture parameters (stack height h, junction distance d; cyclic family constructions) = h up to 45, d up to 50 on scalable families; library h≤10, d≤4
    Evaluation grid choices, not physics fits, but they define where wins/losses appear; once d > n−2−h architectures collapse.
assumptions (5)
  • domain assumption At most two ions per segment; SEPARATE/MERGE/SWAP only at the single gate segment; junctions cannot store ions persistently and obey no-roundtrip/in-transit rules.
    Core hardware model in §I and prompts; matches stated current-device limits and baselines’ constraints.
  • domain assumption A single gate segment is used for all evaluated architectures (hardest shuttling regime; no multi-zone parallel gates).
    Explicit scope choice in §I; results do not automatically transfer to multi-gate-segment scheduling.
  • ad hoc to paper First prompts must supply a complete default algorithm adapted from hand-crafted compilers; open-ended algorithm invention was not relied upon after preliminary failures.
    §III.A states Opus 4.7 did not produce a working compiler without a full algorithm in the prompt.
  • domain assumption Validator functions and TrapGraph/QuantumGate scaffolding are correct oracles the LLM may not modify.
    Correctness of all reported schedules rests on these frozen components (§III.A, Fig. 2).
  • ad hoc to paper Median per-circuit timestep reduction factors are the right summary (vs ratio of suite totals) for comparing compilers.
    §III.B methodological choice; totals still reported and can tell a different story when large circuits dominate.
invented entities (2)
  • LLM-generated linear / branched / general ion_trap_compiler.py instances (Opus 4.7 and Fable 5 chains) independent evidence
    purpose: Executable shuttling compilers under test; primary experimental artifacts.
    New software objects produced by the study; independent evidence is the validator-checked schedules and baseline comparisons, not external prior existence.
  • Cycle-detour and two-arc delivery routing features on general graphs
    purpose: Exploit cycles to bypass intermediates without full merge-swap-separate.
    Described as prompt-required or LLM-added general-architecture mechanisms (§VI); evidence is internal benchmark behavior only.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Efficient LLM-Generated Shuttling Compilers for Complex Trapped-Ion Architectures." pith.science (2026). https://pith.science/paper/F4ODHAIT

@misc{pith2026260724714,
  author       = {Pith},
  title        = {Pith review of: Efficient LLM-Generated Shuttling Compilers for Complex Trapped-Ion Architectures},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/F4ODHAIT}},
  note         = {Machine review of arXiv:2607.24714}
}
read the original abstract

Trapped-ion quantum computers rely on shuttling compilers, which cast an input algorithm into a sequence of ion-qubit movements within a given architecture. We present the first study in which a single frontier large language model (LLM), Claude Opus 4.7, generates and iteratively refines the full Python code of shuttling compilers from written specifications. We start with a compiler for (i) a linear segmented trap, extend it to (ii) a trap with junctions, and finally achieve efficient compilation for (iii) a broad class of connected trap graphs. The compilers for the more general cases are seeded with code from the previous ones. We benchmark the LLM-generated compilers against state-of-the-art hand-crafted ones using a common suite of quantum circuits. The number of shuttling timesteps is reduced by up to 76% for (i) and up to 39% for (ii). For the broad case (iii) of freely connected architectures, we find large variations in the required number of shuttling timesteps, depending on the connectivity. A densely connected, junction-rich architecture yields an order-of-magnitude reduction in shuttling timesteps compared to a corridor-like one. Repeating the complete generation and evaluation with a second frontier LLM, Claude Fable 5, reproduces these findings, with the Fable 5 compilers surpassing the hand-crafted ones more often on the largest circuits. Our results show that an unmodified frontier LLM can produce working, correct, and competitive shuttling compilers without additional manual algorithmic engineering, thus reducing the development time for new architectures from several months to a few days.

Figures

Figures reproduced from arXiv: 2607.24714 by the authors.

Figure 1
Figure 1. Overview of the approach. The three shuttling compilers are generated in a chained sequence of increasing architectural [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Structure of the single-file compiler ion_trap_compiler.py. Boxes in green are the provided, fixed components that the LLM may not change: the outer functions parse_input and validate_and_output and the data classes TrapGraph and QuantumGate. Boxes in blue are the two functions written by the LLM: initial_mapping and compile. The shaded frame groups the QuantumGate objects into the list the pipeline passes along. So… view at source ↗
Figure 3
Figure 3. Construction of the circuit-DAG (b) and the qubit-interaction graph (c) from an example circuit (a). [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Linear architecture, optimized LLM-based compiler [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 5
Figure 5. Figure 5: Branched architecture, optimized LLM-based com [PITH_FULL_IMAGE:figures/full_fig_p012_5.png]
Figure 6
Figure 6. Figure 6: Architecture suitability per circuit class. Each row is one scalable family or the circuit library, and each column one [PITH_FULL_IMAGE:figures/full_fig_p015_6.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

91 extracted references · 2 linked inside Pith

  1. [1]

    - Execute SEPARATE to isolate qa

    If qa shares its vertex with another qubit in current_state: - Move qa’s vertex to a gate vertex. - Execute SEPARATE to isolate qa

  2. [2]

    AlphaRouter: Quantum Circuit Routing with Reinforce- ment Learning and Tree Search,

    pp. 146–156. 56W. Tang, Y. Duan, Y. Kharkov, R. Fakoor, E. Kessler, and Y. Shi, “AlphaRouter: Quantum Circuit Routing with Reinforce- ment Learning and Tree Search,” inIEEE Int. Conf. Quantum Comput. Eng. (QCE), Vol. 1 (Montreal, Canada, Sep. 15–20,

  3. [3]

    Qubit Routing Using Graph Neural Network Aided Monte Carlo Tree Search,

    pp. 930–940. 57A. Sinha, U. Azad, and H. Singh, “Qubit Routing Using Graph Neural Network Aided Monte Carlo Tree Search,” in36th AAAI Conf. Artif. Intell.(Virtual Event, Feb. 22–Mar. 1, 2022) pp. 9935–9943. 58E. Russo, M. Palesi, D. Patti, G. Ascia, and V. Catania, “Op- timizing Qubit Assignment in Modular Quantum Systems via Attention-Based Deep Reinforc...

    arXiv 2022

  4. [4]

    - If qb shares its vertex with another qubit: ·Move qb’s vertex to a gate vertex and execute SEPARATE

    Finalization: When intermediate_qubits == []: - If qa shares its vertex with another qubit: ·Move qa’s vertex to a gate vertex and execute SEPARATE. - If qb shares its vertex with another qubit: ·Move qb’s vertex to a gate vertex and execute SEPARATE. - Move qa to the left neighbor of the gate vertex. - Move qb to the right neighbor of the gate vertex. - ...

  5. [5]

    Move qa to the gate vertex

  6. [6]

    Execute the gate. Two-qubit gate case -- distance reduction via iterative merge-swap-separate: Given: - current_state: Dict[int, List[str]] - QuantumGate with len(QuantumGate.qubits) == 2; call the qubits qa and qb

  7. [7]

    - Otherwise go to step 2

    Trivial case: - If qa and qb are at the same vertex: move that vertex to a gate vertex and execute the gate. - Otherwise go to step 2

  8. [8]

    , ik] be the qubits between qa and qb in linear_ordering

    Initialization: - Build a linear ordering of all qubits by iterating over current_state in ascending key order and concatenating the values: ·linear_ordering: List[str], len == len(qubits) - Let intermediate_qubits = [i1, i2,. . ., ik] be the qubits between qa and qb in linear_ordering. - By definition: ·qa is directly left of i1 in linear_ordering. ·qb i...

Show all 91 references
  1. [9]

    Iterative Reduction: Repeat until intermediate_qubits == []: a) Choose direction: Select the side (qa or qb) that minimizes the approximate number of future timesteps: - qa will be merged with i1, or - qb will be merged with ik. b) Prepare for merge: - If the chosen qubit (qa ...

  2. [10]

    SEPARATE Vertex 3→q[2]→V2, q[1]→V4 Timestep 9:

  3. [11]

    Removing the pair must leave A’s and B’s contents identical to the no-removal trace at every intermediate step

    Roundtrip elimination -- remove a TRANSLATE A→B immediately followed by TRANSLATE B→A when no intervening operation references A or B (as src, dst, or operand vertex). Removing the pair must leave A’s and B’s contents identical to the no-removal trace at every intermediate step

  4. [12]

    Apply passes 1 and 2 alternately to fixpoint

    Consecutive cancellation -- remove: - a SEPARATE immediately followed by a MERGE on the same vertex, - a MERGE immediately followed by a SEPARATE on the same vertex, - a SWAP immediately followed by another SWAP on the same vertex, in each case only when the qubits are not inv...

  5. [13]

    chain of translations

    Grouping -- pack independent operations into the same timestep: Translation timesteps: may contain only TRANSLATE operations. All translations on pairwise disjoint source/destination vertex pairs may be freely grouped. A "chain of translations" along consecutive vertices is al...

  6. [15]

    SEPARATE Vertex 3→q[0]→V2, q[1]→V4 Timestep 3:

  7. [16]

    TRANSLATE q[0]: V2→V1

  8. [17]

    TRANSLATE q[1]: V4→V3

  9. [18]

    TRANSLATE q[2]: V5→V4 Timestep 4:

  10. [19]

    TRANSLATE q[1]: V3→V2 Timestep 5:

  11. [20]

    MERGE V2+V4→Vertex 3 (contains q[1],q[2]) Timestep 6:

  12. [22]

    SWAP Vertex 3 (chain becomes q[2],q[1]) Timestep 8:

  13. [24]

    TRANSLATE q[1]: V4→V5

  14. [25]

    TRANSLATE q[2]: V2→V3

  15. [26]

    TRANSLATE q[0]: V1→V2 Timestep 10:

  16. [27]

    TRANSLATE q[2]: V3→V4 Timestep 11:

  17. [28]

    MERGE V2+V4→Vertex 3 (contains q[0],q[2]) Timestep 12:

  18. [29]

    transit only

    GATE cx q[0],q[2] at Vertex 3 SECTION 10 - CODE QUALITY - Single file, Python 3.12+. All Python libraries are permitted; however, only libraries needed to compute the requested output may be installed. 26 - Determinism: the compiler must produce byte-identical output for ident...

  19. [30]

    Main-axis and stack vertices that are equidistant from a gate vertex are interleaved naturally

    Compute the candidate vertex list: candidates = sorted( [v for v in trap_graph.vertices if not trap_graph.is_junction(v)], key=lambda v: (min(trap_graph.distance(v, gv) for gv in trap_graph.gate_vertices), v) ) This places vertices closest to any gate vertex first, with vertex...

  20. [31]

    next_gate_id(q)

    Walk candidates in order and assign each ordered item (pair or singleton) to the next available candidate vertex. Junction vertices are never used. Override: if the first applicable gate is a two-qubit gate whose qubit set equals items[0], place items[0] at the gate vertex tha...

  21. [32]

    If qa shares its vertex with another qubit, move the whole pair to a chosen gate vertex, evacuate the gate vertex’s two neighbors, emit SEPARATE

  22. [33]

    Move qa to a gate vertex via move()

  23. [34]

    buried 2-chain

    Emit GATE(gv, gate). Stack-extraction prefix: if qa currently sits at slot k > 0 of some stack column (precisely: trap_graph.stack_of(qpos[qa]) is not None and stack_of(qpos[qa])[2] > 0), run the Sec. 6.2 Stack-reordering protocol before step 1, so qa (and any vertex-mate) end...

  24. [35]

    Stack reordering

    The pop must respect the no-roundtrip rule for the junction; the destination of the evicted qubit must not lie on either routing-intermediate path (bfs_path(qa, l) or bfs_path(qb, r)) nor be a gv-neighbor. Without stack-slot eviction, fully-loaded traps remain unsolvable. This...

  25. [36]

    Free space. The stack must have at least one free slot (i.e., its deepest occupied slot is shallower than the bottom; equivalently, the number of currently occupied slots is strictly less than len(trap_graph.stacks_at(j)[stack_index])). This is the only hard requirement

  26. [37]

    The new arrival becomes the next qubit to be popped

    LIFO compatibility (preference, not requirement). The new arrival becomes the next qubit to be popped. Prefer stacks where the new arrival’s next_gate_id is≤the next_gate_id of every qubit already in that stack, so existing occupants are not blocked when their gates come due. ...

  27. [38]

    Among eligible stacks, prefer the one whose junction minimizes trap_graph.distance from the new arrival’s likely future location (gate vertex of its next gate)

    Distance to next consumer. Among eligible stacks, prefer the one whose junction minimizes trap_graph.distance from the new arrival’s likely future location (gate vertex of its next gate)

  28. [39]

    As a secondary tie-breaker, prefer the stack whose junction is closest to the qubit’s current vertex, to minimize the cost of the push itself

    Distance to current location. As a secondary tie-breaker, prefer the stack whose junction is closest to the qubit’s current vertex, to minimize the cost of the push itself. Stack reordering is possible but only by full-or-partial evacuation, never in place: qubits inside a sta...

  29. [40]

    no intervening operation references A or B

    Roundtrip elimination -- remove a TRANSLATE A→B immediately followed by TRANSLATE B→A when no intervening operation references A or B (as src, dst, or operand vertex). Removing the pair must leave A’s and B’s contents identical to the no-removal trace at every intermediate ste...

  30. [41]

    Apply passes 1 and 2 alternately to fixpoint, always working on the current post-removal stream

    Consecutive cancellation -- remove: - a SEPARATE immediately followed by a MERGE on the same vertex, - a MERGE immediately followed by a SEPARATE on the same vertex, - a SWAP immediately followed by another SWAP on the same vertex, in each case only when the qubits involved do...

  31. [42]

    chain of translations

    Grouping -- pack independent operations into the same timestep: Translation timesteps: may contain only TRANSLATE operations. All translations on pairwise disjoint source/destination vertex pairs may be freely grouped. A "chain of translations" along consecutive vertices is al...

  32. [43]

    GATE cx q[0],q[1] at Vertex 3 Timestep 2:

  33. [44]

    SEPARATE Vertex 3→q[1]→V2, q[0]→V4 Timestep 3:

  34. [45]

    TRANSLATE q[0]: V4→V5

  35. [46]

    TRANSLATE q[1]: V2→V3

  36. [47]

    TRANSLATE q[2]: V0→V1 Timestep 4:

  37. [48]

    TRANSLATE q[0]: V5→V6

  38. [49]

    TRANSLATE q[1]: V3→V4

  39. [50]

    TRANSLATE q[2]: V1→V2 Timestep 5:

  40. [51]

    MERGE V2+V4→Vertex 3 (contains q[2],q[1]) Timestep 6:

  41. [52]

    GATE cx q[1],q[2] at Vertex 3 Timestep 7:

  42. [53]

    SWAP Vertex 3 (chain becomes q[1],q[2]) Timestep 8:

  43. [54]

    SEPARATE Vertex 3→q[1]→V2, q[2]→V4 Timestep 9:

  44. [55]

    TRANSLATE q[1]: V2→V1

  45. [56]

    TRANSLATE q[2]: V4→V3

  46. [57]

    TRANSLATE q[0]: V6→V5 Timestep 10:

  47. [58]

    TRANSLATE q[1]: V1→V0

  48. [59]

    TRANSLATE q[2]: V3→V2

  49. [60]

    TRANSLATE q[0]: V5→V4 Timestep 11:

  50. [61]

    MERGE V2+V4→Vertex 3 (contains q[2],q[0]) Timestep 12:

  51. [62]

    v <= M" or

    GATE cx q[0],q[2] at Vertex 3 SECTION 10 - CODE QUALITY - Single file, Python 3.12+. All Python libraries are permitted; however, only libraries needed to compute the requested output may be installed. - Determinism: the compiler must produce byte-identical output for identica...

  52. [63]

    slot > 0

    If either endpoint is in a stack at slot > 0 (precisely: trap_graph.stack_of(qpos[q]) is not None and stack_of(qpos[q])[2] > 0), run the stack-extraction routine described in Sec. 6.2 (Stack-reordering for trapped endpoints, including the slot-0 special case). This is the high...

  53. [64]

    6.2 single-qubit-style separation if either shares a vertex)

    Isolate both endpoints (Sec. 6.2 single-qubit-style separation if either shares a vertex)

  54. [65]

    Method choice each iteration

    Iteration loop applying Sec. 6.2 Step 2’s method-choice logic per iteration (cheapest of Stack-Method, Swap-Method, Park-the-endpoint; see "Method choice each iteration" in Sec. 6.2). Bound the iteration count at num_vertices·6 + 30. As a practical fallback rule when the cost ...

  55. [66]

    6.2 Step 1)

    Final delivery: bring qa to its target gv-neighbor and qb to the other gv-neighbor (according to the assignment chosen in Sec. 6.2 Step 1). On failure, try the rotation-through-gv variant described in Sec. 6.2 case (b) Step 6. Two-assignment rule (which gv-neighbor each endpoi...

  56. [67]

    If the dance fails, run the full case (b) protocol from Sec

    If gv still holds a non-endpoint chain after delivery: first try direct evacuate(gv, blocked = {l, r}); if that fails, run the snapshot dance (park qa off the (gv, l, r) triangle; evacuate gv; re-deliver qa to its gv-neighbor; re-deliver qb to the other). If the dance fails, r...

  57. [68]

    Outer retries (when the inner attempt fails for the current gv / role): (a) Try the next gate vertex in combined-distance order (Sec

    Clear junctions, emit MERGE, emit GATE. Outer retries (when the inner attempt fails for the current gv / role): (a) Try the next gate vertex in combined-distance order (Sec. 6.2 Step 1). (b) For each gate vertex, try both role assignments -- (qa→l, qb→r) and (qa→r, qb→l). Note...

  58. [69]

    If n holds a keep qubit, skip this candidate

    Evacuate n if it is non-empty and the chain at n is not a keep qubit (use the standard evacuate with blocked = {gv}). If n holds a keep qubit, skip this candidate

  59. [70]

    Translate q_gv from gv to n (this is the reseat)

  60. [71]

    12.5 step 1 (now with q_gv at n instead of at gv)

    Retry the entire inner attempt from Sec. 12.5 step 1 (now with q_gv at n instead of at gv)

  61. [72]

    gv empty after step 1

    On success, return. On failure, restore the snapshot and try the other candidate. why it is required -- every retry level (a)-(e) above assumes the keep-set semantics is unchanged across retries: keep qubits are strict-protected by every evacuate call. When the only blocker is...

  62. [73]

    If d == L - 1, the stack is at its bottom; fail (no room)

    Find the deepest occupied slot d (the largest index i such that slot_i is non-empty). If d == L - 1, the stack is at its bottom; fail (no room)

  63. [74]

    Empty slots between occupied ones are skipped

    Emit cascade pushes from the deepest occupied slot outward toward slot 0: for each slot index i from d down to 0, if slot_i is currently occupied, emit TRANSLATE(slot_i, slot_{i+1}). Empty slots between occupied ones are skipped. After this sweep, slot_0 (stk[0]) is empty

  64. [75]

    Walk the chain at v to junction j along its bfs_path, treating j as a transit-only vertex (do not invoke move()/walk_path() which would refuse to terminate at a junction; instead emit the T(s,t) sequence directly and evacuate any non-keep obstacles along the way)

  65. [76]

    t is either initially empty or is the source of some other op already accepted into the batch

    Emit TRANSLATE(j, stk[0]). Chain-rule applicability: step 3’s walk-to-j fills j during the same translation batch, and step 4’s T(j, stk[0]) consumes the chain at j. By Sec. 6.3 grouping rule (b) ("t is either initially empty or is the source of some other op already accepted ...

  66. [77]

    A stack vertex is off the retrieve main path, so parking there frees the entire opposite-subtree main corridor as obstacle-buffer space

    Park one endpoint on a stack vertex of its own subtree (not a main-axis vertex). A stack vertex is off the retrieve main path, so parking there frees the entire opposite-subtree main corridor as obstacle-buffer space

  67. [78]

    Deliver the other endpoint to its gate-neighbor without hard-confining obstacles to its own subtree -- obstacles may now buffer in the freed corridor and in side stacks

  68. [79]

    Decongest: move every non-endpoint that ended up on the parked endpoint’s retrieve path out into the mover’s subtree. 48

  69. [80]

    Retrieve the parked endpoint from its stack vertex to its gate-neighbor; the retrieve move evacuates any residual obstacle

  70. [81]

    Compilation time

    Clear the gate vertex (Sec. 12.6 rotation if it is sandwiched). Try the method for both (parked, mover) role assignments, each inside its own snapshot/restore transaction. Rationale: a depth-1 side-stack buffers only one obstacle, so a single corridor with one occupied stack c...

  71. [82]

    12.15(d))

    Isolate every qubit (single-qubit chains -- Sec. 12.15(d))

  72. [83]

    By (a) this succeeds whenever the trap has free space

    Funnel qa to gv with an unconstrained move(qa, gv). By (a) this succeeds whenever the trap has free space

  73. [84]

    Drop qa on ga (evacuate ga, then T(gv, ga))

    Read qb’s side; let gb be the gate-neighbor on qb’s side and ga the other. Drop qa on ga (evacuate ga, then T(gv, ga)). Choosing ga opposite qb’s side makes qb’s subtree the one to be drained

  74. [85]

    12.15(c) (with its pre-decongest and nearest-first stash, Sec

    Run the rotor conveyor of Sec. 12.15(c) (with its pre-decongest and nearest-first stash, Sec. 12.15(e)) to deliver qb to gb

  75. [86]

    0", "1"], [

    Succeed iff qa and qb sit on the two gate-neighbors, gv empty, no junction occupied. Step 2’s funnel is robust by construction; step 4’s rotor carries each obstacle past qb with neither needing room to pass. Together they make delivery total: no congestion pattern defeats this...

  76. [87]

    Topology. A junction is still any vertex of degree > 2, a non-junction vertex has degree 1 or 2, and the gate-vertex constraints are unchanged (degree exactly 2; neither neighbor is a junction). Every junction rule still applies on the general graph: junctions hold ions only i...

  77. [88]

    REMOVE OR REPLACE

    No stacks, no main axis. Qubit vertices are simply non-junction non-gate vertices that hold up to 2 ions each, with no LIFO or ordering constraint. The existing tree-specific routing structures (stack-shaped side arms with depth-ordered slots, main-axis indexing, per-stack end...

  78. [89]

    obstacles can be detoured around for free

    Cycles relax the no-roundtrip rule at cycle-member junctions. The structural difference between a tree and a cycle-containing graph is not "obstacles can be detoured around for free" -- a pure cycle is topologically a linear chain with the endpoints joined, so the 1-wide-corri...

  79. [90]

    On a graph with no cycles at all, method (a) is unavailable on every iteration and the router falls through to (b), (c), (d) automatically

    The set of routing methods that must remain after the adaptation: (a) cycle-detour (only applies when alternative_path returns a path and its cost beats the direct-arc-plus-eviction cost -- often loses on uniformly packed cycles); (b) park-the-endpoint at any empty non-junctio...

  80. [91]

    park slot

    Park-the-endpoint generalizes. In the existing linear-trap code, "park slot" meant either a stack column head or a main-axis-end vertex. On the general graph it means any empty non-junction vertex that lies off the routing-intermediate paths between the two endpoints’ current ...

  81. [92]

    Total vertex count: 2 * n + 2

    = 2 * n + 1. Total vertex count: 2 * n + 2. D3. cycle_with_chord. A cycle of length 2 * n + 3 plus one chord edge connecting two non-adjacent cycle vertices. The chord adds no new vertices, but its two endpoints (already cycle vertices) become junctions of degree 3. Non-juncti...

  82. [93]

    Gate vertex: an end-rung mid-vertex (rung 0 or rung P), whose two neighbors are corner path-vertices, both non-junctions

    + (P + 1) = 3 * (P + 1) = 6 * n - 9. Gate vertex: an end-rung mid-vertex (rung 0 or rung P), whose two neighbors are corner path-vertices, both non-junctions. (Interior-rung mid-vertices do not qualify because their neighbors are internal path junctions.) Tests routing on a tw...

  83. [2024]

    TrapSIMD: SIMD-Aware Compiler Optimization for 2D Trapped-Ion Quantum Machines,

    pp. 127–133. 49J. Ruan, H. Zhang, X. Fang, A. Li, W. C. Campbell, E. Hud- son, D. Hayes, H. Haeffner, T. Humble, J. Palsberg, and Y. Ding, “TrapSIMD: SIMD-Aware Compiler Optimization for 2D Trapped-Ion Quantum Machines,” (2025), arXiv:2504.17886. 50J. Heckey, S. Patil, A. Java...

    2025 arXiv

Pith tools

Reviewed July 31, 2026 · model on record in the stance chip above.