A quantum program describes operations on logical qubits: abstract units of information that a circuit can address without specifying their exact physical location. A quantum processor is less abstract. It has a collection of physical qubits, a set of supported operations and, on many architectures, restrictions on which qubits can interact directly.
A compiler must connect those two worlds. It takes a circuit written for a logical computation and transforms it into operations the selected hardware can execute. This includes translating gates into a supported instruction set and deciding where to place quantum information as the computation proceeds.
The intriguing part is that there may be many correct ways to carry out the same calculation, and some require substantially more work from the hardware than others.
Three qubits and a missing connection
Imagine three physical qubits in a line: left, middle and right. The device can perform a direct two-qubit interaction between neighbors. Now consider a logical circuit involving three qubits, A, B and C. It needs interactions between A and B, between B and C, and later between A and C.
No matter how we initially assign A, B and C to the three physical positions, only two of the three logical pairs can be adjacent at once. The three required interactions form a triangle; the hardware connections form a line. A fixed placement cannot make every requested pair directly accessible.
The compiler is not merely translating one gate at a time; it is making choices whose consequences extend across the circuit.
The compiler must respond. It might change the placement of quantum states during the computation by inserting a SWAP operation. A SWAP exchanges the quantum states held in two physical locations, allowing a later interaction to take place between neighboring qubits. Other hardware-native transformations may also be available. Either way, a logical circuit that looked compact on paper may need extra physical operations.
And the moment a state moves, subsequent decisions change. A SWAP inserted to enable the next gate can put a different pair in favorable positions later. The compiler is not merely translating one gate at a time; it is making choices whose consequences extend across the circuit.
The right mapping depends on the whole conversation
Suppose most of the circuit's interactions are between A and C, with only occasional operations involving B. A mapping that keeps A and C adjacent could avoid considerable routing. But if the circuit changes its pattern halfway through, a different strategy might be better overall.
This is the layout and routing problem. Layout chooses how logical qubits are initially assigned to physical positions. Routing accommodates interactions that are not supported by the current placement, potentially changing the mapping as it proceeds.
The compiler searches among alternative layouts, routes and gate decompositions. Those choices form a classical optimization problem associated with running a quantum computation. It is not a QUBO problem by definition, nor does compiling a circuit require a quantum optimizer. Classical algorithms do much of the decision-making that makes quantum hardware usable.
Fewer gates is not always the only goal
When a gate must be decomposed into several native operations, extra work can affect runtime and errors. On noisy hardware, two-qubit operations are often particularly consequential. But simply counting gates misses other effects. Some operations can run in parallel; others must wait. Qubits and connections can differ in calibration and error rates. A circuit with fewer operations may still have greater depth or be less favorable on a particular device.
The difference can be a substantial part of the practical cost of running it.
A good compiler therefore needs a target and an objective. Is it trying to reduce depth, two-qubit gate count, an estimated error measure or compilation time? How much computation may it spend improving the circuit before execution begins? The answer may change between an interactive experiment and a circuit that will be executed repeatedly.
There is another subtlety: correctness is not identical to a good performance score. Compilation must preserve the intended computation under the relevant notion of equivalence. For circuits with measurements or classical control, this may require more than comparing two ideal unitary matrices. Only after correctness is established does it make sense to discuss which implementation is preferable.
Why this is an algorithm problem
Qiskit's transpilation workflow provides a concrete example. Its stages include layout, routing, translation to target-supported operations, further optimization and scheduling where applicable. These are distinct responsibilities, though some implementations combine decisions across stages. The existence of multiple stages does not mean there is one best fixed order of independent choices. https://qiskit.qotlabs.org/docs/guides/transpile
The opportunity for better algorithms lies in recognizing interactions across these choices. A placement that saves one SWAP may cost several later. A gate decomposition that looks efficient before routing may no longer be attractive after mapping to a device. Choosing well requires both an understanding of the quantum computation and effective classical search.
Quantum circuit compilation is therefore an unusually tangible example of optimization serving quantum computing. The quantum algorithm determines what the circuit should achieve; the compiler helps determine how to make that computation fit the machine. The difference can be a substantial part of the practical cost of running it.