Compilation and Transpilation

10.1 Backend Targets

Our circuit asks for a CNOT between qubits 0 and 2, but the device has only a line of qubits in which 0 touches 1 and 1 touches 2. Before the compiler can do anything, it needs a precise description of the device. What must that description contain? We consider the operations first, then the connections between qubits.

10.1.1 Native operations

Which gates can the device actually perform? In Qiskit the device is called a backend, and its description is called its target. The target lists the native operations together with the qubits on which each one is available. It often adds how long each operation takes and how accurately it was last calibrated.

Is a list of gate names enough? No, because an operation may exist on some qubits or qubit pairs and not on others. That is exactly the constraint our CNOT runs into. To see the problem without contacting a device, the companion builds a toy target by hand. Its native gates are rz, sx, x and cx, where rz is a Z rotation and sx is \(\sqrt X\), a quarter turn about X. Its connections form a line of three qubits.

10.1.2 Connectivity and device constraints

Before asking how to run our CNOT, we must say which qubit is meant. The qubits of our program are logical qubits: variables of the algorithm. The device’s qubits are physical qubits: places where the computation happens. A compiler chooses which physical qubit holds each logical one, and that correspondence can change as the circuit runs.

Now suppose logical qubits 0, 1 and 2 sit on physical qubits 0, 1 and 2 of the line. The CNOT from 0 to 2 cannot be applied directly. One way out is to swap the states of physical qubits 1 and 2. Logical qubit 2 then sits next to logical qubit 0, and the CNOT can act on physical qubits 0 and 1. A swap is three CNOTs, so this one logical CNOT becomes four. Some devices also allow a two-qubit gate in only one direction, and reversing it costs extra one-qubit gates. These costs depend on the circuit and on where we place it.

10.2 Transpilation

We now know what the device offers and what our circuit asks for. Rewriting one into the other is called transpilation. It has to solve two problems in our example: H is not a native gate, and the CNOT acts on qubits that are not neighbours. We take the gate problem first, then the placement problem.

10.2.1 Decomposition and synthesis

How does the compiler run H on a device whose only one-qubit gates are rz, sx and x? It rewrites H in those gates. The compiled circuit contains \(R_z(\pi/2)\,\sqrt X\,R_z(\pi/2)\), which equals H up to a global phase of \(\pi/4\), and Qiskit records that phase with the circuit. Breaking an operation into a known sequence of smaller ones is called decomposition.

Some operations have no exact short decomposition in the available gates. For these, the compiler constructs a sequence that approximates the operation within a stated error. That is called synthesis. Transpilation combines decomposition and synthesis with placement, routing, and simplification. Its optimization level, from 0 to 3, selects how much effort these steps use. A higher level tries harder, but it does not guarantee a smaller or better circuit for every input.

10.2.2 Layout, routing, and optimization

Now the CNOT. The compiler first fixes an initial layout, which places each logical qubit on a physical one. The companion fixes it to the identity, logical \(k\) on physical \(k\). Then routing inserts swaps wherever a two-qubit gate acts on non-neighbours. The compiled circuit for the line is exactly the plan we worked out by hand:

global phase: π/4
         ┌─────────┐┌────┐┌─────────┐
q_0 -> 0 ┤ Rz(π/2) ├┤ √X ├┤ Rz(π/2) ├──■──
         └─────────┘├───┬┘└─────────┘┌─┴─┐
q_1 -> 1 ─────■─────┤ X ├──────■─────┤ X ├
            ┌─┴─┐   └─┬─┘    ┌─┴─┐   └───┘
q_2 -> 2 ───┤ X ├─────■──────┤ X ├────────
            └───┘            └───┘

Three CNOTs swap physical qubits 1 and 2, and the fourth acts on physical 0 and 1. The swap is never undone, so the circuit ends with logical qubit 1 on physical qubit 2 and logical qubit 2 on physical qubit 1. This leftover rearrangement is the final layout, which the companion prints as [0, 2, 1].

The final layout has a consequence for testing. If we compared the compiled circuit’s matrix directly with the original, the swapped wires would make a correct compilation look wrong. Operator.from_circuit reads the layout recorded with the compiled circuit and undoes it, so the comparison is between the same logical qubits.

10.3 Compiler Inspection

The compiler made choices: a layout, a route, a decomposition. Can we control those choices, reproduce them and report what they cost? We first look at the object that carries out the compilation, then check its output for meaning and count its resources.

10.3.1 Pass managers

What actually runs when we compile? Transpilation is a sequence of steps called passes. Some passes analyse the circuit, for example by finding which gates act on non-neighbours. Others transform it, by choosing a layout, inserting swaps, or decomposing gates. An object that holds the passes and runs them in order is a pass manager.

Qiskit’s convenience function transpile builds a standard pass manager for us and runs it. The companion builds that pass manager explicitly with generate_preset_pass_manager, giving it the optimization level, the native gates, the connections, the initial layout and a seed. Then pass_manager.run(qc) compiles the circuit. Some passes make random choices, and fixing seed_transpiler makes those choices reproducible within the tested implementation. Running several seeds and keeping the best result is a legitimate search, but its classical cost belongs in the report.

The companion wraps this in a function, compile_for(coupling_map), so that it can compile the same circuit for two connection patterns. CouplingMap.from_line(3) is our line. CouplingMap.from_full(3) connects every pair of qubits.

10.3.2 Logical equivalence and physical resource counts

Does the compiled circuit still mean the original? For each connection pattern, the companion checks that Operator.from_circuit(compiled) is equivalent to the logical operator. Where does the extra cost come from? On the full pattern, the CNOT needs no routing and the count stays at one. On the line, it becomes four, as we predicted. The single-qubit gates are the same in both, so the difference is entirely the cost of connectivity.

"""Runnable companion for Quantum Programming, Chapter 10."""
from qiskit import QuantumCircuit
from qiskit.transpiler import CouplingMap, generate_preset_pass_manager
from qiskit.quantum_info import Operator

qc = QuantumCircuit(3)
qc.h(0)
qc.cx(0, 2)

def compile_for(coupling_map):
    # The same preset pipeline that transpile() builds internally.
    pass_manager = generate_preset_pass_manager(
        optimization_level=1, basis_gates=["rz", "sx", "x", "cx"],
        coupling_map=coupling_map, initial_layout=[0, 1, 2], seed_transpiler=19)
    return pass_manager.run(qc)

line = compile_for(CouplingMap.from_line(3))
full = compile_for(CouplingMap.from_full(3))
for compiled in (line, full):
    assert Operator.from_circuit(compiled).equiv(Operator(qc))
assert full.count_ops()["cx"] == 1 and line.count_ops()["cx"] > 1
print("Logical", qc.count_ops())
print("Line", line.count_ops(), "full", full.count_ops())
print("Line final layout:", line.layout.final_index_layout())

Companion script: chapter_10.py.

For larger circuits, the full matrix comparison is impossible, by the \(4^n\) count we derived for operators. Then we rely on tests of each component, structured tests on chosen inputs, and checks of observables, each stated with its limits. A resource report should also include any added ancillas, the routing, the precision of any synthesis, and the target it assumes.

Our compiled circuit is ready for a device, but so far the device was a description we made up. Running on real hardware needs an account, a choice of backend, and a budget. How do we run a tested program there and interpret what comes back?

Sources and further study: IBM, transpiler API.