MQT Compiler Collection

• MQT Compiler Collection is a modular ecosystem for quantum-classical compilation, transforming high-level descriptions into hardware-specific instructions.
• It employs a classical-first methodology using MLIR dialects with dual representations (QC and QCO) to optimize and verify quantum circuits.
• Benchmarking, simulation, and verification are tightly integrated to ensure robust mapping, synthesis, and efficient qudit as well as qubit workflows.

Searching arXiv for papers on the MQT Compiler Collection and closely related MQT compiler components to ground the article in current research. The MQT Compiler Collection denotes the compiler- and design-automation-focused part of the Munich Quantum Toolkit (MQT), an open-source collection of tools for quantum computing developed by the Chair for Design Automation at the Technical University of Munich. It is not a single monolithic compiler. Rather, it is a modular ecosystem spanning mapping, synthesis, optimization, verification, simulation, benchmarking, and shared infrastructure, and, in later work, it is presented as a blueprint for a future-proof quantum-classical compilation framework built on MLIR and intended to support the full path from high-level algorithms to hardware-specific instructions (Wille et al., 2024, Burgholzer et al., 9 Apr 2026).

1. Scope and conceptual position

In the handbook view, MQT is explicitly organized around support for applications or high-level realization support, classical simulation of quantum circuits, compilation, verification, quantum error correction, physical design, and enabling data structures and core methods such as decision diagrams, ZX-calculus, and SAT encodings or solvers (Wille et al., 2024). Within that landscape, the compiler collection is best understood as the subset of MQT that transforms high-level or target-independent descriptions into hardware-aware or hardware-specific executable forms, while remaining tightly coupled to benchmarking and equivalence checking.

This distributed character is a defining feature. The handbook does not describe “the compiler” as one package; instead, compiler-related functionality is distributed across specialized but interoperable tools such as MQT Core, MQT QMAP, MQT QCEC, MQT DDSIM, and MQT Bench, with additional synthesis, optimization, device-selection, and architecture-specific methods referenced throughout the MQT portfolio (Wille et al., 2024). A common misconception is therefore to equate the MQT Compiler Collection with routing alone. Mapping is central, but the collection also includes HDL-based reversible synthesis, mixed-dimensional compilation, learned compiler-flow construction, pre-compilation techniques for recurring workloads, and, in the MLIR-based blueprint, a full-stack quantum-classical architecture.

The conceptual shift in the later blueprint is equally important. Earlier quantum toolchains are characterized there as largely quantum-first and centered on static, pure quantum circuits. The MQT Compiler Collection is instead framed as adopting a classical-first methodology: it extends mature compiler infrastructure and makes quantum one domain inside a broader heterogeneous system, rather than constructing a separate compiler universe for quantum programs (Burgholzer et al., 9 Apr 2026). This suggests that the term “compiler collection” refers not only to a set of packages, but also to an architectural stance on how quantum and classical compilation should coexist.

2. Architectural evolution toward an MLIR-based framework

The 2026 blueprint presents the MQT Compiler Collection as a full-stack compilation pipeline from high-level quantum-classical programs down to hardware-specific instructions. Input programs originate in languages or frameworks such as OpenQASM or Qiskit; they are imported into an MLIR-based representation centered first on the QC dialect; they are transformed into the QCO dialect for optimization; after optimization they can be converted back into QC; and finally they are lowered to low-level forms such as LLVM IR and QIR, from which simulators or physical hardware can be targeted (Burgholzer et al., 9 Apr 2026).

MLIR is not treated there as an implementation detail. The framework relies on MLIR’s dialect system, progressive lowering, conversion framework, canonicalization infrastructure, and translation framework. This allows the compiler to reuse existing classical dialects such as arith for arithmetic and scf for structured control flow, rather than reimplementing them inside a quantum-specific infrastructure (Burgholzer et al., 9 Apr 2026). The resulting design is explicitly modular and progressive rather than monolithic.

This architectural evolution also reframes interoperability. A later integration paper situates MQT in an MLIR-centered ecosystem that includes frameworks such as PennyLane/Catalyst and potentially CUDA-Q and QIR-based stacks. Historically, MQT relied on its own internal representation, the C++-based QuantumComputation IR in MQT Core. In the MLIR integration work, MQT Core is said to provide dedicated MLIR dialects starting from version 3.3.3, and the MQTOpt dialect is introduced as an MLIR form that mirrors MQT Core IR semantics closely enough to minimize disruption to the existing code base (Hopf et al., 5 Jan 2026).

The practical significance is that the compiler collection is no longer presented merely as a toolbox of separate algorithms. It becomes a dialect- and pass-oriented framework in which MQT functionality can be surfaced through MLIR plugins, conversion passes, and interoperable representations. This does not imply that all MQT passes have become fully MLIR-native. The integration paper is explicit that QMAP still operates through MQT Core IR, with export and re-import around it, so the present state is a bridge architecture rather than a complete internal rewrite (Hopf et al., 5 Jan 2026).

3. Intermediate representations and compilation semantics

A central design decision in the MLIR blueprint is the separation between two quantum dialects, QC and QCO, each aligned with a different phase of compilation. The QC dialect is the imperative interface dialect. It uses the type !qc.qubit, supports qc.alloc and qc.dealloc, standard gates such as qc.h, qc.x, and qc.rz, non-unitary operations such as qc.measure and qc.reset, and first-class modifiers such as qc.ctrl, qc.inv, and qc.pow. It is intended as the natural front-end and back-end representation, closely reflecting the reference semantics used by languages such as OpenQASM and frameworks such as Qiskit (Burgholzer et al., 9 Apr 2026).

The QCO dialect, by contrast, is optimization-oriented and adopts value semantics. Operations consume input quantum states and produce output quantum states, which the paper characterizes as effectively modeling qubits as linear types. In practice this makes the program a dataflow graph whose dependencies are encoded directly in MLIR use-def chains rather than an auxiliary custom DAG (Burgholzer et al., 9 Apr 2026). The main advantage is that advanced optimization becomes easier because adjacency and data dependence are explicit rather than encoded only through mutation and program order.

The bridge between both forms is bidirectional. The pass from QC to QCO is called linearization: qubit references are replaced by qubit-state values and explicit dataflow is constructed by tracking the latest value for each qubit. The reverse pass, from QCO back to QC, is called bufferization: reference semantics are reconstructed from the dataflow graph (Burgholzer et al., 9 Apr 2026). This duality is the architectural core of the framework. Imperative form is retained for language interfacing and hardware realism; functional value-semantics form is used for optimization.

The integration work with PennyLane/Catalyst adds a second IR perspective. Catalyst’s Quantum dialect uses SSA form and represents quantum operations generically, while MQTOpt uses dedicated operations that stay close to MQT Core IR semantics. The conversion pipeline catalystquantum-to-mqtopt, mqt-qmap, and mqtopt-to-catalystquantum shows how MQT passes can be embedded into a broader MLIR flow without reducing everything to text-based exchange formats such as OpenQASM (Hopf et al., 5 Jan 2026). This suggests that the long-term semantics of the MQT Compiler Collection are increasingly defined by IR conversion and pass composition rather than by a single canonical in-memory circuit object.

4. Principal components and compilation methodologies

The collection’s major tools occupy distinct niches in the compilation stack.

Component	Primary role	Characteristic methodology
MQT QMAP (Wille et al., 2023)	Quantum circuit mapping	Exact MaxSAT/SMT mapping and heuristic $A^*$-based routing
SyReC Synthesizer (Adarsh et al., 2022)	HDL-based reversible synthesis	Cost-aware and line-aware synthesis from SyReC
MQT Predictor (Quetschlich et al., 2023)	Device selection and meta-compilation	Supervised device selection plus RL-trained device-specific compilers
MQT Qudits (Mato et al., 2024)	Mixed-dimensional compilation	DITQASM, qudit state preparation, single- and two-qudit synthesis
Gate-level pre-compilation (Quetschlich et al., 2023)	Runtime-latency reduction for recurring workloads	Predictive encoding and specialization of pre-compiled circuits
RL compiler-flow optimization (Quetschlich et al., 2022)	Pass-sequence construction	MDP-based flow learning across Qiskit and TKET passes

MQT QMAP is the hardware-aware placement-and-routing engine of the collection. It treats quantum circuit mapping as the task of assigning logical qubits to physical qubits and inserting the additional operations needed to satisfy device connectivity constraints. Its exact mapper transforms the problem into MaxSAT and solves it with Z3 to obtain gate-optimal solutions in terms of the minimum possible number of SWAP gates, while its heuristic mapper uses $A^*$ search and initial-layout strategies to scale to circuits with hundreds of qubits and hundreds of thousands of gates (Wille et al., 2023). In the MQT architecture, QMAP occupies the device-specific compilation stage.

SyReC Synthesizer fills a different niche: high-level reversible HDL synthesis. It accepts programs written in SyReC and generates reversible circuits in a push-button manner. The key trade-off is between cost-aware synthesis, which introduces additional circuit lines to obtain moderate gate cost, and line-aware synthesis, which minimizes line usage by storing intermediate results on available lines and later restoring overwritten values via inverse operations (Adarsh et al., 2022). In the quantum interpretation emphasized by the paper, each circuit line corresponds to a qubit, so the choice is directly between line count and gate cost.

MQT Predictor adds an orchestration layer above conventional compiler passes. It combines a supervised-learning device selector with reinforcement-learning-based compiler generation. In the reported instantiation, the framework supports more than 500 training circuits and seven devices, and, compared to Qiskit’s and TKET’s most optimized fixed flows for all devices, produces circuits within the top-3 out of 14 baselines in more than 98% of cases while frequently outperforming any tested combination by up to 53% when optimizing for expected fidelity (Quetschlich et al., 2023). This places it less as a backend compiler in the narrow sense than as a meta-compiler and compiler recommender.

MQT Qudits extends the collection beyond qubit-only workflows. It defines DITQASM for mixed-dimensional registers, supports compilation to hardware gate sets, and includes routines for state preparation, single-qudit unitary synthesis, and two-qudit unitary synthesis. Its compilation methods rely on mixed-dimensional decision diagrams, energy level graphs for single-qudit compilation, and decompositions of arbitrary two-qudit unitaries into crot and pswap sequences (Mato et al., 2024). This makes the collection relevant not only to standard qubit hardware but also to mixed-dimensional and qudit devices.

At the workflow level, two additional contributions broaden the compiler collection’s meaning. A reinforcement-learning framework for compiler optimization models compilation as a Markov Decision Process and learns pass sequences across Qiskit and TKET actions; in the reported experiments it outperforms individual compilers in 73% of cases regarding expected fidelity (Quetschlich et al., 2022). A separate pre-compilation method shifts expensive compilation effort offline by constructing a predictive, general-purpose circuit for a recurring problem class and then specializing it at runtime; for QAOA MaxCut and a satellite mission-planning case study, it reduces compilation time by several orders of magnitude while maintaining comparable compiled circuit quality (Quetschlich et al., 2023). Together, these works show that the MQT Compiler Collection includes not only circuit-to-hardware translation, but also compiler-flow construction and compilation-time amortization.

5. Benchmarking, verification, simulation, and shared infrastructure

The compiler collection is anchored by infrastructure that makes empirical evaluation and semantic validation first-class concerns. MQT Bench provides the benchmark substrate. It supports four abstraction levels—algorithmic level, target-independent level, target-dependent native gates level, and target-dependent mapped level—and contains more than 70,000 benchmark circuits ranging from 2 to 130 qubits. Access is provided through a GitHub repository, a Python package, and an easy-to-use web interface (Quetschlich et al., 2022). This cross-level organization is specifically intended to increase comparability, reproducibility, and transparency across tools operating at different points in the compilation pipeline.

MQT Core is described in the handbook as the backbone of the toolkit. It provides a comprehensive intermediate representation for quantum computations, a decision diagram package, and a ZX-calculus library, and it underpins the implementation of simulation, verification, and compilation tools (Wille et al., 2024). This shared substrate matters because it allows the collection to combine transformation, analysis, and reasoning methods without reducing interoperability to ad hoc text-based exchange.

Verification is represented primarily by MQT QCEC. The handbook formulates equivalence checking by composing one circuit with the inverse of another: for circuits $G = g_1,\dots,g_m$ and $G' = g'_1,\dots,g'_n$, if they are equivalent then

$G \cdot G^{\prime -1} = I,$

with $$G^{\prime -1} = (g'_n)^\dagger,\dots,(g'_1)^\dagger$$ (Wille et al., 2024). The practical point is that the identity admits a compact representation in decision diagrams, so equivalence checking can be made efficient when intermediate representations stay close to identity. This makes post-compilation verification an explicit part of the collection, not an external afterthought.

Simulation infrastructure is likewise coupled to compilation. The handbook presents MQT DDSIM as a decision-diagram-based simulator that supports strong simulation, weak simulation, approximation techniques, noise-aware simulation, hybrid Schrödinger–Feynman techniques, dynamic circuits, and mixed-dimensional systems (Wille et al., 2024). In practice, this means that compiler development in MQT is embedded in a closed loop of synthesis, mapping, simulation, equivalence checking, and benchmarking.

A second common misconception is that benchmarking and verification sit outside the compiler collection proper. In MQT they are structurally integrated. Benchmarks are provided at multiple abstraction levels, mapped circuits can be checked for equivalence, and simulation backends can validate or analyze compiled outputs. This integration is one of the collection’s most distinctive traits.

6. Limitations, open challenges, and future trajectory

The literature is explicit that several MQT compiler components are introduced as tool papers or architectural blueprints rather than complete algorithmic treatments. The SyReC Synthesizer paper does not provide formal semantics of SyReC constructs, explicit synthesis transformation rules, benchmark suites with quantitative synthesis results, runtime or scalability studies, formal verification beyond simulation, or discussion of target-specific quantum gate decompositions (Adarsh et al., 2022). The MLIR blueprint likewise does not provide a full formal semantics, type system, grammar, or rewrite calculus, and it does not include a numerical benchmarking section or runtime table (Burgholzer et al., 9 Apr 2026). These omissions do not negate the architectural contribution, but they delimit its current evidentiary scope.

Mixed-dimensional compilation remains especially open-ended. MQT Qudits is explicit about current limitations: the DITQASM interpreter is still in its nascent stages; no suitable mixed-dimensional QIR yet exists in the framework; multi-body gate compilation is not yet supported; scalable verification is not yet integrated; and support for classical control flow and mid-circuit measurement is future work (Mato et al., 2024). This suggests that the collection’s qudit branch is foundational infrastructure rather than a finalized analogue of mature qubit transpilers.

Workflow-level methods also impose conditions. The gate-level pre-compilation method requires a predictive encoding whose representative instance overapproximates future instances, and it works best when runtime specialization can be achieved by deleting or neutralizing gates rather than inserting new ones; otherwise the original mapping can become invalid and recompilation may be needed (Quetschlich et al., 2023). Learned orchestration methods depend on representative training data and may require retraining when devices, calibration data, supported passes, or optimization objectives change (Quetschlich et al., 2023, Quetschlich et al., 2022).

The overall trajectory, however, is clear. The MLIR blueprint identifies Full-Stack Support, Next-Generation Programs, Comprehensive Optimization, Rigorous MLIR Adoption, and Modern Standards—specifically current LLVM or MLIR releases, QIR 2.0 with opaque pointer support, and OpenQASM 3.x—as design principles (Burgholzer et al., 9 Apr 2026). The MLIR integration work adds a concrete path for surfacing MQT functionality through plugins and dialect conversions rather than brittle exchange chains (Hopf et al., 5 Jan 2026). Taken together, these developments indicate that the MQT Compiler Collection is evolving from a federation of high-quality specialized tools into a more unified quantum-classical compilation framework whose distinguishing commitments are modularity, interoperability, and explicit integration of compilation with verification, simulation, and benchmarking.