Introduction

A quantum algorithm is an idea about how to use quantum mechanics to solve a computational problem. A quantum circuit is a more concrete description of that idea: it says which quantum operations act on which qubits, in which order, and where measurements occur. A quantum computer, however, does not execute an abstract idea directly. It executes instructions that fit a particular device, with its own available gates, qubit layout, timing rules, control electronics, calibration data, and noise behavior.

A quantum compiler is the engineering system that connects these layers.

In classical computing, a compiler translates a program written in a language such as C, Rust, or Python-related bytecode into a lower-level form that can run on hardware or a virtual machine. Along the way, it analyzes the program, rewrites it, optimizes it, and checks that the translation preserves the intended meaning. This broad view of compilation—as translation plus analysis and optimization—is standard in classical compiler construction (Aho et al., 2006). Quantum compiler engineering keeps that same spirit, but the objects being compiled are quantum programs: circuits, hybrid quantum-classical workflows, parameterized ansätze, measurement-controlled operations, and eventually device-specific instructions.

The purpose of this book is to teach that engineering path carefully: from quantum circuits and intermediate representations to optimization, mapping, verification, and execution on real hardware.

Why quantum compilation matters

A simple quantum circuit can be drawn on a page in a few lines. For example, the following two-qubit circuit prepares a Bell state:

q0: ──H──■──
         │
q1: ─────X──

The first gate, H, is a Hadamard gate. It maps a computational basis state such as \(|0\rangle\) into a superposition. The second operation is a controlled-NOT gate, often written CNOT or CX; it flips the target qubit when the control qubit is in state \(|1\rangle\). Starting from \(|00\rangle\), this circuit produces

\[ \frac{|00\rangle + |11\rangle}{\sqrt{2}}, \]

which is an entangled state: the two qubits cannot be described as two independent single-qubit states. The circuit model, including gates, measurements, tensor-product state spaces, and entanglement, is a standard model of quantum computation (Nielsen & Chuang, 2010).

On paper, the circuit is short. On real hardware, many questions immediately appear.

Suppose the device does not provide CNOT as a native gate, but instead provides a controlled-Z gate, written CZ, plus single-qubit rotations. The compiler may replace CNOT by an equivalent sequence using CZ and Hadamard gates:

control: ─────■─────
              │
target:  ──H──Z──H──

This rewrite is valid because conjugating CZ by Hadamards on the target qubit implements the same unitary transformation as CNOT. Here, a unitary transformation means a reversible linear transformation that preserves quantum-state norm, and therefore preserves total probability.

Now suppose the two logical qubits in the circuit are assigned to two physical qubits that are not directly connected on the hardware coupling graph. A coupling graph is a graph whose vertices are physical qubits and whose edges indicate which pairs can directly participate in two-qubit gates. If two qubits are not adjacent, the compiler may insert SWAP gates to move quantum states through connected qubits. But a SWAP is not free: it usually decomposes into multiple two-qubit gates, and two-qubit gates are often among the noisier and slower operations on current devices. This means a compiler must not merely make the program executable; it must make careful engineering choices about cost.

The example is tiny, but it already shows the central work of a quantum compiler:

• preserve the mathematical meaning of the program;
• express operations using the target device’s native gate set;
• place logical qubits onto physical qubits;
• route interactions through limited connectivity;
• reduce avoidable gates and depth;
• respect measurement, timing, and classical-control constraints;
• use hardware information when it improves execution quality.

This is why quantum compilation is not just “format conversion.” It is a major part of quantum computer system design.

The first principle: preserve meaning

A compiler is allowed to change the form of a program, but not its intended meaning.

For a quantum circuit without measurement, the meaning is often described by a unitary matrix. A matrix is a rectangular array of numbers; in quantum computing those numbers are usually complex numbers. A unitary matrix \(U\) satisfies

\[ U^\dagger U = I, \]

where \(U^\dagger\) is the conjugate transpose of \(U\), and \(I\) is the identity matrix. This condition says that the operation preserves inner products and probabilities. In physical terms, an isolated quantum evolution must be norm-preserving and reversible, and unitary matrices provide the mathematical representation used in the circuit model (Nielsen & Chuang, 2010).

For example, two consecutive Hadamard gates on the same qubit cancel:

q: ──H──H──

is equivalent to

q: ───────

because \(H^2 = I\). A compiler pass may safely remove the pair if no measurement, reset, or classically controlled operation occurs between them.

A compiler pass is one transformation or analysis step inside a compiler. One pass might remove adjacent inverse gates. Another pass might merge rotations. Another might choose an initial mapping from logical qubits to physical qubits. In a well-engineered compiler, each pass has a clear responsibility and a clear correctness condition.

For circuits with measurement, correctness becomes subtler. A measurement converts quantum information into classical information, and its result is probabilistic. After measurement, later operations may depend on the classical bit obtained. Thus, two circuits may be equivalent not because they have the same unitary matrix, but because they produce the same probability distribution over measurement outcomes, or because they induce the same input-output behavior on a larger quantum-classical system. This book will return to these distinctions in Chapter 8.

Why quantum compilers differ from classical compilers

Quantum compilation inherits many ideas from classical compilation: intermediate representations, data-flow analysis, optimization passes, scheduling, target descriptions, and testing. But quantum programs obey different physical and mathematical rules.

First, quantum data cannot be copied in the same way classical data can. The no-cloning theorem states that there is no physical operation that can copy an arbitrary unknown quantum state perfectly (Wootters & Zurek, 1982). This matters for compiler design. A classical compiler can often duplicate a value, store a backup, or reuse an expression freely. A quantum compiler must track quantum data carefully, because unknown quantum states cannot simply be copied for convenience.

Second, most quantum gates before measurement are reversible. A classical program may overwrite a variable:

x = x + 1

If the old value of x is no longer needed, the overwrite is usually harmless. A quantum operation on an isolated system cannot erase information in that way; it must correspond to a reversible unitary transformation. This is one reason reversible logic, uncomputation, ancilla management, and garbage cleanup are central topics in quantum compilation.

Third, measurement changes the situation. Before measurement, a qubit can be in a superposition such as

\[ \alpha |0\rangle + \beta |1\rangle, \]

where \(\alpha\) and \(\beta\) are complex amplitudes satisfying \(|\alpha|^2 + |\beta|^2 = 1\). Measuring in the computational basis gives outcome \(0\) with probability \(|\alpha|^2\) and outcome \(1\) with probability \(|\beta|^2\) (Nielsen & Chuang, 2010). After measurement, the measured value can control later operations. A compiler therefore needs to represent both quantum operations and classical control.

Fourth, real quantum devices are noisy. Current and near-term devices have limited qubit counts, imperfect gates, finite coherence times, readout errors, and calibration-dependent behavior. Preskill introduced the term NISQ—Noisy Intermediate-Scale Quantum—to describe devices large enough to be scientifically interesting but not yet protected by full fault-tolerant error correction (Preskill, 2018). In this setting, compilation choices can strongly affect experimental results. For example, mapping a circuit to qubits with better calibrated two-qubit gates can improve the likelihood of obtaining useful outcomes; noise-adaptive compilation methods explicitly exploit this kind of device information (Murali et al., 2019).

These differences make quantum compiler engineering both familiar and new. Familiar, because we still build structured translation pipelines. New, because the semantics come from quantum mechanics and the target hardware is often fragile.

From program to hardware: the compilation journey

A useful way to understand this book is to imagine a quantum program moving through several levels of description.

At the top, a programmer may write an algorithm in a high-level library. The program might express phase estimation, amplitude amplification, a variational ansatz, or a quantum Fourier transform. At this stage, the code may contain mathematical structure that is not visible in a low-level gate list.

The next level is often a circuit or a quantum intermediate representation. An intermediate representation, or IR, is an internal program form used by a compiler. It is not necessarily meant to be written by humans. It is designed to make analysis and transformation easier. Classical compilers rely heavily on IRs because source languages and machine targets are both too diverse to connect directly in a clean way (Aho et al., 2006). Quantum compilers use the same idea: an IR can represent gates, qubits, measurements, parameters, control flow, and hardware constraints in a form suitable for compiler passes.

Some quantum IRs are close to circuits. Others include richer control flow and classical computation. OpenQASM 3, for example, was designed to extend earlier assembly-style circuit descriptions with broader support for timing, classical computation, and real-time control features needed by quantum programs (Cross et al., 2022). More general compiler infrastructures, such as MLIR, show how reusable IR frameworks can support many domain-specific compilation pipelines (Lattner et al., 2021), and similar ideas influence quantum compiler design.

After the IR is built, the compiler applies analyses and transformations. An analysis computes information without necessarily changing the program. For example, a dependency analysis determines which gates must happen before which other gates. An optimization changes the program to improve some cost metric while preserving meaning. For example, a local optimization may replace

q: ──Rz(a)──Rz(b)──

with

q: ──Rz(a+b)──

when the two rotations are adjacent and no intervening operation prevents the merge.

Eventually, the compiler must target hardware. A target describes what the backend can execute: native gates, qubit connectivity, timing constraints, measurement rules, and sometimes calibration data. A backend is the execution destination, such as a simulator, a superconducting quantum processor, an ion-trap device, or a pulse-level control system.

The output may be a gate-level program, a scheduled instruction stream, or a lower-level pulse description. This book focuses mainly on gate-level and IR-level compilation, while also explaining where pulse-aware and hardware-aware compilation enter the engineering picture.

A small example of compiler thinking

Consider this circuit:

q0: ──H──■────■──H──
         │    │
q1: ─────X────X─────

A beginner may read it gate by gate. A compiler reads it through several questions.

First: do any gates cancel? The two CNOT gates are identical and adjacent except for no intervening operation on either qubit. Since CNOT is its own inverse, the pair cancels:

q0: ──H────────H──
q1: ──────────────

Then the two Hadamard gates on q0 also cancel:

q0: ──────────────
q1: ──────────────

The entire circuit is equivalent to the identity operation.

This example is simple, but it teaches a core lesson: a compiler must understand algebraic identities. It cannot optimize quantum circuits well by treating gates as mere text symbols. It needs the semantics of operations.

Now change the example:

q0: ──H──■──M──
         │
q1: ─────X─────

Here M means measurement of q0. The compiler must be more careful. It cannot freely move the measurement earlier or later unless it proves that doing so preserves the observable behavior of the program. Measurement is not just another reversible gate; it creates classical information and changes the quantum state. This is why correctness conditions around measurement are a central part of quantum compiler engineering.

What this book will build

The early chapters establish the language of the field. Chapter 1 explains what a quantum compiler does in the quantum software stack. Chapters 2 and 3 build the mathematical and circuit foundations: vector spaces, tensor products, unitary gates, measurements, and circuit semantics. Chapter 4 introduces universal gate sets and cost models, because a compiler must know not only what is correct, but also what is expensive.

The middle chapters develop the machinery of compilation. You will study compiler inputs, programming languages, circuit formats, intermediate representations, semantic correctness, circuit analysis, and local optimization. These topics answer questions such as:

What information should a compiler keep?

When are two circuits equivalent?

How can a compiler know which gates commute?

How can it simplify a circuit without changing its measurement results?

Later chapters move toward synthesis, mapping, scheduling, and hardware execution. You will learn how arbitrary operations are decomposed into native gates, how limited connectivity forces routing decisions, how schedules are built under timing constraints, and how noise-aware compilation uses calibration data.

The final chapters turn to larger engineering concerns: variational algorithms, fault-tolerant compilation, verification, debugging, real toolchains, and research frontiers. The goal is not only to explain known techniques, but to help you think like a quantum compiler engineer.

The attitude of this book

Quantum compilation sits at the intersection of mathematics, physics, computer architecture, and software engineering. That can make the subject feel large. We will manage that size by moving from first principles to practical systems.

When a mathematical object appears, we will explain what it means before relying on it. When a compiler technique appears, we will connect it to a small example. When hardware constraints matter, we will ask what the compiler can know and what it cannot know. When an optimization seems obvious, we will ask what correctness condition justifies it.

The central promise of a compiler is disciplined transformation. In quantum computing, that discipline is especially important because the program’s meaning may be hidden in amplitudes, phases, entanglement, and measurement statistics. A quantum compiler is successful when it changes the program enough to run well on a real target, but not so much that it changes the computation being performed.

That is the engineering challenge this book is about.

References

Aho, A. V., Lam, M. S., Sethi, R., & Ullman, J. D. (2006). Compilers: Principles, Techniques, and Tools (2nd ed.). Pearson/Addison-Wesley.

Cross, A. W., Bishop, L. S., Sheldon, S., Nation, P. D., & Gambetta, J. M. (2022). OpenQASM 3: A broader and deeper quantum assembly language. ACM Transactions on Quantum Computing, 3(3), Article 12.

Lattner, C., Amini, M., Bondhugula, U., Cohen, A., Davis, A., Pienaar, J., Riddle, R., Shpeisman, T., Vasilache, N., & Zinenko, O. (2021). MLIR: Scaling compiler infrastructure for domain specific computation. In Proceedings of the 2021 IEEE/ACM International Symposium on Code Generation and Optimization (CGO).

Murali, P., Baker, J. M., Javadi-Abhari, A., Chong, F. T., & Martonosi, M. (2019). Noise-adaptive compiler mappings for noisy intermediate-scale quantum computers. In Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS ’19).

Nielsen, M. A., & Chuang, I. L. (2010). Quantum Computation and Quantum Information (10th anniversary ed.). Cambridge University Press.

Preskill, J. (2018). Quantum computing in the NISQ era and beyond. Quantum, 2, 79.

Wootters, W. K., & Zurek, W. H. (1982). A single quantum cannot be cloned. Nature, 299, 802–803.