Turning Quantum Compiler Configuration Selection Upside Down: A Top-Down Paradigm

1 Introduction

• For ising_n10, O1 achieves about 0.20 Hellinger fidelity on a fixed device, compared with 0.12 for O3.Across devices, the same fixed O3 configuration also yields substantially different fidelities.Source: §1 · p. 2
• 213 cases (79.5%) have a feasible device whose best option combination has lower estimated fidelity than another feasible device’s default O3 configuration.This indicates that a poor device choice can impose a fidelity ceiling that later option tuning cannot overcome.Source: §1 · p. 2
• Quantum configuration selection jointly chooses a device and compiler options, while SOTA separates device selection from RL-based option tuning.The first device decision sets hardware constraints and error characteristics for subsequent compilation stages.Source: §1 · pp. 1–2
• Each circuit has 960 discrete device-option configurations, making exhaustive offline enumeration feasible for empirical oracles and top-down selection rules.The approach reuses rules extracted from oracle configurations rather than repeatedly searching candidate configurations.Source: §1 · p. 2
• Ten evaluated LLMs remain substantially below the oracle, largely preferring overly aggressive optimization, layout, and routing choices.The paper then uses oracle decisions from sampled circuits to distill transferable rules and build QCompass, a rule-guided ML framework; the rules improve LLM selection and QCompass offers a favorable quality–latency trade-off.Source: §1 · p. 2
• The paper’s contributions include QuOptBench’s 268 circuits with empirical oracle configurations and evaluations of direct LLM selection and QCompass against search and retrieval baselines.The evaluations also examine generalization to additional circuits and devices.Source: §1 · p. 2

2.1 Task Description

• Each QuOptBench case jointly selects a device and compiler options using seven circuit features and device features for capacity, noise, and connectivity.Circuit features include qubit count, depth, communication, critical depth, entanglement ratio, parallelism, and liveness.Source: §2.1 · p. 2

2.2.1 Foundation Benchmarks.

• QuOptBench draws on QASMBench and VeriQBench circuits spanning quantum algorithms, variational circuits, and random circuits, represented in Open-QASM 2.0.The supplied passage identifies these as the foundational benchmark sources.Source: §2.2.1 · p. 3

2.2.2 Search Space.

• Each circuit has 960 candidate configurations across four fake backends and compiler options; approximation, scheduling, and seed settings are fixed or excluded.Approximation degree is fixed at 1.0, scheduling at None, and seed_transpiler at 42; default choices resolving to methods already searched are excluded.Source: §2.2.2 · p. 3

2.2.3 Evaluation Metric.

• Estimated fidelity multiplies expected gate and measurement fidelities from target-device error information, then normalizes by input-operation count to reduce circuit-size bias.For configurations of the same circuit, the normalization preserves their relative ordering and therefore does not change the oracle configuration.Source: §2.2.3 · p. 3

2.2.4 Brute-Force Search Process.

• The search enumerates all 960 device-option combinations with seed 42, a 600-second compilation timeout, and highest effective estimated fidelity as the oracle criterion.Shorter compilation time breaks ties; five circuits exceeded the timeout under default O3. The search used 8,345.40 CPU-hours, or about 618 wall-clock hours with 20 workers, and is feasible offline but too costly per-circuit.Source: §2.2.4 · p. 3

2.2.5 Level Partition.

• The 268 circuits are partitioned by optimization headroom: 104 have under 1% improvement, 88 have 1–10%, and 76 exceed 10%.Level 2 circuits average 21.8 qubits and depth 106.7; Levels 1 and 3 average 36.7 and 31,801, and 24.5 and 39,982, respectively, with very deep outliers contributing to the latter depth averages.Source: §2.2.5 · p. 4

2.3 Optimal Configuration Distribution

• FakeAuckland and FakeBrisbane account for 47% and 37% of device choices, while O2 and O3 account for 31% and 37% of optimization levels.O0 appears in 16% of oracle configurations, mainly for single-qubit-dominated circuits where stronger optimization brings little fidelity benefit and O0 compiles faster.Source: §2.3 · p. 4
• Sabre is used in more than half of oracle cases for both layout and routing, while translation choices are more diverse.Overall, no single configuration dominates, motivating circuit-specific configuration selection.Source: §2.3 · p. 4

• QuOptBench is a benchmark providing empirical oracle configurations for each circuit.Source: §2.4 · p. 4
• The benchmark supports measuring improvement over standard configurations and the remaining gap to the oracle.Source: §2.4 · p. 4
• Oracle construction is computationally expensive, but its cost is incurred only once for reproducible evaluation.Source: §2.4 · p. 4

3 An Initial Attempt at Direct Selection with LLMs

• Ten LLMs are evaluated on QuOptBench to characterize direct configuration selection.Source: §3 · p. 4, §3.1 · p. 4

3.1 Evaluation Settings

• The evaluation uses improvement in F_eff over ODA3 as its primary metric and compilation time as an efficiency metric.Source: §3.1 · p. 4
• The protocol reports per-level average gain and Better/Equal/Worse counts, with paired Wilcoxon signed-rank tests against ODA3.Pairs with zero differences are excluded; p < 0.05 is treated as statistically significant.Source: §3.1 · p. 4
• Prompts provide circuit and device features plus candidate options, and request a configuration maximizing F_eff with compilation time as a tie-breaker.Source: §3.1 · p. 4

3.2 Evaluation Results

• Vanilla LLMs underperform ODA3 across all three levels and remain far from the oracle, with all LLM–ODA3 differences statistically significant (p < 0.05).Table 3 reports average F_eff improvement and compilation time across the three levels, together with the oracle.Source: Table 3 · p. 5, §3.2 · pp. 5–6

3.3.2 Configuration Aggressiveness Metric.

• GPT-5.5 favors more aggressive options, while oracle configurations also use less aggressive choices that can achieve higher fidelity and shorter compilation time.GPT-5.5 selects FakeAuckland about 20% more often and FakeBrisbane about 20% less often than the oracle.Source: §3.3.2 · p. 6
• The aggressiveness score treats stronger hardware and more complex, transformation-intensive compiler options as more aggressive.For devices, the score reflects qubit capacity, topology connectivity, and gate error; the device-related scores are averaged as one component.Source: §3.3.2 · p. 6
• Positive ΔAggressiveness dominates across all ten LLMs, indicating that their selected configurations tend to be more aggressive than the oracle configurations.Source: §3.3.2 · p. 6, Figure 4 · p. 6

4.1 Sample Collection and Classification

• Cases were classified using fidelity, compilation-time, and aggressiveness gaps, with empirical thresholds of 0.01, 1.5, and 2, respectively.The classification distinguishes fidelity-loss and time-overhead cases by which configuration is more aggressive, alongside near-optimal cases.Source: §4.1 · pp. 6–7, Table 5 · p. 7
• Of the 68 sampled cases, 52.94% had ODA3 more aggressive than the oracle, 27.94% were near-optimal, and 7.35% had the oracle more aggressive.The other reported sampled category was Time-overhead/ODA3 more aggressive at 11.76%; three categories were empty in QuOptBench.Source: §4.1 · p. 7

4.2 Rule Generation and Distillation

• Claude-Opus-5 analyzed oracle and ODA3 configurations with circuit and device features to produce case-level rules with explicit applicability conditions.Recurring patterns were consolidated, then manually checked against supporting cases for consistency and redundancy.Source: §4.2 · pp. 7–8
• Distilled rules favor circuit- and device-specific choices: device width and connectivity, optimization intensity, and translation method should match circuit characteristics.Low-occupancy circuits can benefit from wider devices, while high-communication circuits favor connectivity and lower two-qubit error; synthesis suits unsupported or higher-arity operations.Source: §4.2 · p. 8

5.1 Predictive Model Training

• Four Extra Trees models predict circuit-level optimization opportunity, configuration-level fidelity gain, timeout risk, and compilation-time overhead.The models use circuit features, devices, and options as inputs; Extra Trees are chosen for structured feature interactions and lower inference overhead than neural or LLM predictors.Source: §5.1 · p. 9

5.2 Rule-Guided Inference

• QCompass predicts optimization headroom over ODA3 and assigns KEEP, SAFE, or SEEK modes, ranging from retaining ODA3 to broader configuration changes.The policy gate uses predicted opportunity and timeout risk to avoid unnecessary modifications for near-optimal cases.Source: §5.2 · p. 9

5.2.2 Rule-Guided Candidate Generation.

• For SAFE and SEEK circuits, distilled rules match circuit and device features to applicable options, narrowing the candidate space toward configurations more likely to be suitable.SAFE permits at most 50% option changes around ODA3 while allowing rule-supported device switches; SEEK considers all rule-supported device and option changes.Source: §5.2.2 · p. 10

5.2.3 Candidate Scoring and Selection.

• QCompass scores candidates by predicted fidelity gain, timeout risk, and compilation-time overhead, prioritizing fidelity while treating risk and time as penalties.It selects the candidate with the highest unified score.Source: §5.2.3 · p. 10
• Scoring a rule-pruned candidate set with lightweight models avoids repeated online compilation and high LLM reasoning latency.The paper presents this as a fast realization of top-down configuration selection.Source: §5.2.3 · p. 10

6.1 Evaluation Settings

• Evaluation uses QuOptBench cases not used for rule distillation, plus 100 non-overlapping QCircuitBench circuits for the new-circuit study, and compares bottom-up RL and BO with retrieval and LLM methods.The baseline setup includes a re-implementation of MQT Predictor under Qiskit V2.4.1 and joint or device-aware RL/BO variants.Source: §6.1 · p. 10

6.2 Effectiveness of Distilled Rules for Configuration Selection (RQ.1)

• Distilled rules improve all evaluated LLMs across three levels; Qwen3.5-397B-A17B gains 20.37% over ODA3 on Level 3, while most models still degrade slightly on Level 1.Seven of ten models achieve statistically significant positive gains on Level 3; Level 2 results are more mixed.Source: §6.2 · p. 11, Table 7 · p. 11

6.3 Effectiveness of QCompass (RQ.2)

• QCompass outperforms all baselines on Levels 2–3 and trails Device-Aware BO by only 0.012 percentage points on Level 1, at 3.28 s versus 2,856.87 s per case.Its improvements on Levels 2 and 3 are statistically significant (p<0.001).Source: §6.3 · p. 11, Table 8 · p. 12

6.4 Adaptation to New Devices and Circuits (RQ.3)

• On 100 new circuits and four new devices, QCompass improves over ODA3 by 9.06% on average, while the two ML+RL methods yield negative improvements.The RL option policies and QCompass are applied without retraining in this evaluation.Source: Figure 7 · p. 12, §6.4 · p. 13

6.5 Evaluation with Noise-Aware Execution Fidelity on the Noisy Simulator (RQ.4)

• On 63 small and medium QASMBench circuits, QCompass achieves the largest mean noise-aware improvement: 5.71% over ODA3 (p<0.001).The direction matches the estimated-fidelity results, although the improvement magnitude differs.Source: Figure 8 · p. 12, §6.5 · p. 13

6.3 Effectiveness of QCompass (RQ.2)

• QCompass averages about 3.30 seconds per case, slower than RL and NN-Retrieval but faster than GPT-5.5, Qwen3.5-397B-A17B, and BO.The reported averages are about 0.001–0.15 seconds for RL and NN-Retrieval, 17 seconds for GPT-5.5, 110 seconds for Qwen3.5-397B-A17B, and 820–3,320 seconds for BO.Source: §6.3 · p. 13

6.6 Ablation and Sensitivity Study (RQ.5)

• Removing the policy gate causes the largest Level-1 degradation, removing Risk harms Levels 1 and 2 through timeouts, and removing rules mainly harms Levels 2 and 3.Replacing Claude-Opus-5’s 13 rules with alternatives also weakens QCompass; more rules alone do not ensure stronger results.Source: Table 9 · p. 13, §6.6 · p. 13
• Among tested parameters, τseek has the largest impact: its default performs best, while τrisk, λr, and λt are relatively robust within the evaluated ranges.Setting τsafe to 0.001 reduces Level-3 performance, whereas values above 0.0015 produce nearly unchanged results across levels.Source: Figure 9 · p. 14, §6.6 · p. 14

Compiler Auto-tuning

• Quantum compiler tuning has used heuristic and RL-based methods, but only two studies focus on compiler configuration selection with bottom-up RL.The passage identifies those studies as [49].Source: §7 · p. 14
• Classical compiler auto-tuning also includes similarity-based retrieval and LLM-guided optimization alongside heuristic and RL approaches.Source: §7 · p. 14

Quantum Software Engineering

• Quantum software engineering spans compiler tuning, performance and time prediction, testing, program repair, and quantum code generation.Source: §7 · p. 14

Internal Validity

• Oracle construction is bounded by the selected devices, option space, timeout policy, and estimated-fidelity proxy.The authors use identical devices, option spaces, and settings across methods to mitigate this threat.Source: §8 · p. 14
• The MQT Predictor re-implementation cannot exactly match the original because it was developed under Qiskit V0.39.2 rather than the study’s V2.4.1 setting.The authors follow its reported two-stage methodology and model choices, with training steps increased by 10×.Source: §8 · p. 14

External Validity

• Results may not generalize to substantially different workloads, hardware architectures, or future compiler versions, and broader compiler and real-hardware evaluations remain future work.Most experiments use estimated fidelity; real devices may additionally involve calibration drift, crosstalk, and runtime noise.Source: §8 · p. 14

Conclusion

• The paper constructs QuOptBench with empirical oracle configurations and uses these oracles to distill transferable configuration rules for new circuits.Source: §9 · p. 14
• QCompass is a rule-guided framework for fast configuration selection and achieves the best overall quality–latency trade-off compared with baselines.Source: §9 · p. 14
• Future work targets broader quantum compilers, larger and evolving device pools, real hardware, more efficient oracle construction, and continual rule adaptation.Source: §9 · p. 14