---
title: MQT Compiler Collection
url: https://www.emergentmind.com/topics/mqt-compiler-collection
type: topic
---

# MQT Compiler Collection

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 [2405.17543, 2604.08674].

## 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 [2405.17543]. 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 [2405.17543]. 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 [2604.08674]. 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 [2604.08674].

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 [2604.08674]. 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 [2601.02062].

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 [2601.02062].

## 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 [2604.08674].

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 [2604.08674]. 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 [2604.08674]. 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 [2601.02062]. 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** [2301.11935] | Quantum circuit mapping | Exact MaxSAT/SMT mapping and heuristic \(A^*\)-based routing |
| **SyReC Synthesizer** [2212.05903] | HDL-based reversible synthesis | Cost-aware and line-aware synthesis from SyReC |
| **MQT Predictor** [2310.06889] | Device selection and meta-compilation | Supervised device selection plus RL-trained device-specific compilers |
| **MQT Qudits** [2410.02854] | Mixed-dimensional compilation | DITQASM, qudit state preparation, single- and two-qudit synthesis |
| **Gate-level pre-compilation** [2305.04941] | Runtime-latency reduction for recurring workloads | Predictive encoding and specialization of pre-compiled circuits |
| **RL compiler-flow optimization** [2212.04508] | 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 [2301.11935]. 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 [2212.05903]. 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 [2310.06889]. 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 [2410.02854]. 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 [2212.04508]. 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 [2305.04941]. 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 [2204.13719]. 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 [2405.17543]. 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\) [2405.17543]. 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 [2405.17543]. 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 [2212.05903]. 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 [2604.08674]. 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 [2410.02854]. 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 [2305.04941]. Learned orchestration methods depend on representative training data and may require retraining when devices, calibration data, supported passes, or optimization objectives change [2310.06889, 2212.04508].

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 [2604.08674]. The MLIR integration work adds a concrete path for surfacing MQT functionality through plugins and dialect conversions rather than brittle exchange chains [2601.02062]. 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.

Source: https://www.emergentmind.com/topics/mqt-compiler-collection