A Software Methodology for Compiling Quantum Programs

Thomas Haner,1 Damian S. Steiger,1 Krysta Svore,2 and Matthias Troyer1, 2, 3

1Theoretische Physik, ETH Zurich, 8093 Zurich, Switzerland2Quantum Architectures and Computation Group, Microsoft Research, Redmond, WA (USA)

3Microsoft Research Station Q, Santa Barbara, CA (USA)

Quantum computers promise to transform our notions of computation by offering a completelynew paradigm. To achieve scalable quantum computation, optimizing compilers and a correspond-ing software design flow will be essential. We present a software architecture for compiling quantumprograms from a high-level language program to hardware-specific instructions. We describe thenecessary layers of abstraction and their differences and similarities to classical layers of a computer-aided design flow. For each layer of the stack, we discuss the underlying methods for compilationand optimization. Our software methodology facilitates more rapid innovation among quantumalgorithm designers, quantum hardware engineers, and experimentalists. It enables scalable com-pilation of complex quantum algorithms and can be targeted to any specific quantum hardwareimplementation.

Keywords: Quantum Computing, Compilers, Quantum Programming Languages

I. INTRODUCTION

The field of high-performance computing will be revo-lutionized by the introduction of scalable quantum com-puters. Today, the majority of high-performance com-puting time is dedicated to solving problems in quan-tum chemistry and materials science. These problemswould dramatically benefit from better classical algo-rithms or new models of computation that further re-duce the processing time. One such model, as suggestedby Richard Feynman [1], is quantum computation, whichtakes advantage of quantum mechanics to obtain expo-nential speedups or improvements of solution. Feynmanproposed to use quantum computing to efficiently per-form the simulation of physical systems [2], preciselyin areas such as quantum chemistry and materials sci-ence. Since then, a variety of quantum algorithms haveemerged, providing up to exponential speedups over theirclassical counterparts for problems in quantum chem-istry [3, 4], materials science [5], cryptography [6], andmachine learning [7–10]. A complete list of algorithmscan be found in Ref. [11]. In addition to quantum algo-rithmic improvements, significant advances in quantumhardware implementations have recently been made, sug-gesting imminent scalability. The design of a scalabledesign flow for quantum computing is timely in order toprogram and compile to the rapidly evolving landscapeof quantum devices.

Quantum computers are unlike existing hardware ar-chitectures. A quantum computer will be intimately con-nected to a (potentially large) classical computer and willoperate akin to a coprocessor, similar to GPUs today.See Figure 1 for an illustration. A classical computerwill control the operations performed on the quantumcomputer and will also provide methods for maintaininga fault-tolerant computation. The hardware architecturewill require fast feedback between the quantum chip andthe classical processor to ensure fault tolerance and ahigh quantum clock speed. In many implementations,

$ ./shor 34571- Generating circuit- Executing- Result: 181, 191 $ ./sim_hubbard- Generating circuit

Low-level classical controlhardware at a few Kelvin

Quantum hardware at afew milikelvin

CPUCCPPUU

Q

Figure 1. Quantum computers will be used as acceleratorscontrolled by classical hardware. In many implementations,qubits must be kept at very low temperatures inside a cryo-genic device. Control of the system requires minimization ofheat dissipation and fast communication, potentially requir-ing staging classical control processors and memory units atvarious temperatures, including at least one classical com-puter at room temperature.

the quantum bits of information, called qubits, must bemaintained at ultra-low temperatures inside a cryogenicdevice. In turn, classical processing and memory unitsfor controlling the quantum computation will need to belocated at several different temperatures, in order to min-imize heat dissipation, maximize communication speedsbetween the classical and quantum hardware, and ensureminimal disturbance to the quantum system.

While classical computing benefits from a plethora ofhigh-level programming languages and optimizing com-pilers, quantum computing remains mostly described atthe level of logic operations, compiled and manually op-timized. Recently, a handful of languages and compilershave been introduced. However, a complete end-to-endsoftware methodolgy for compiling and optimizing quan-tum programs is lacking. We propose a scalable softwaredesign flow for compilation and optimization of quantumprograms. By scalable, we mean the design enables pro-gramming any quantum algorithm of any size for any

arX

iv:1

604.

0140

1v1

[cs

.PL

] 5

Apr

201

6

2

Quantumprogram

Host languagecompiler

High-levelcompilers

Low-levelcompilers

Layoutand QEC

Mapping tohardware

eDSL QIR QIR QIR LLQIR

Libraryinterfaces

Compiledlibraries

...

hadamard(0)

cphase(pi/2,0,1)

hadamard(1)

...

function shor(N)

...

CUa=control(Ua)

QPE[CUa](c,x)

r=cfe(measure(c))

...

...

CUa=control(Ua)

qstd.QPE(CUa,c,x)

m=measure(c)

r=math.cfe(m)

...

...

hadamard(0)

tgate(1)

cnot(0,1)

...

... ...

h(0x013)

cx(0x013,0x014)

cx(0x013,0x015)

...

Figure 2. The proposed toolchain for quantum programming: The quantum program is implemented in an embedded domain-specific language (eDSL) and then translated to hardware instructions using a series of compilers, which generate quantumintermediate representations (QIR) of the code. Pre-compiled libraries are linked against prior to creating the logical layoutand applying error correction, since this will produce more efficient code. The resulting low-level quantum intermediaterepresentation (LLQIR) is then mapped to hardware.

target architecture.

Our software design flow is shown in Figure 2. At thetop of our design stack is a high-level language in whichone writes quantum programs. Quantum programs con-sist of an intimate mixture of classical and quantum in-structions. Therefore, we argue the high-level languageshould be an embedded domain specific language (eDSL)to maximally leverage existing classical infrastructure.At the bottom, our methodology supports a vast varietyof backends, such as simulators, emulators, resource ana-lyzers, or any proposed quantum hardware implementa-tion. Our layered methodology provides modularity andflexibility for the future. The high-level compilers arehardware-agnostic and, combined with quantum metafunctions (e.g., conditional instructions and user anno-tations), enable an unprecedented level of optimizationof quantum code.

Our software methodology enables rapid innovationin both quantum algorithms and hardware components.Its development in advance of a fully scalable hardwarearchitecture allows verification of the software stack andtesting of hardware constituents, through simulation andanalysis of components. It also enables the study of earlydesign decisions, which for emerging technologies canresult in substantial cost savings. A scalable quantumsoftware stack and hardware architecture is a complexsystem; our software design enables communicationbetween algorithm designers, quantum engineers, andexperimental physicists, and early definition of thenecessary interfaces between the software and hardwaresystems. We outline a framework for automated pro-gramming of and compilation to a scalable quantumcomputer that is critical for early definition and devel-opment of software and hardware components, whetherthe hardware backend is an ion trap, superconductingsystem, quantum dot, or topological quantum computer.

Related Work. One of the earliest proposals fora scalable software methodology for quantum compilingdates back a decade [12] and presents significant steps ofany quantum computing design flow. Our work expandsupon this work, extending the stack elements by showinghow to integrate, e.g., tuned quantum libraries of arith-metic, subroutines, and quantum gates, and providingconcrete details of the compilers and optimizers in thestack. Later work presents a more detailed softwarearchitecture [13], however the components are specificto a quantum dot architecture and the focus is mainlyon the pipelined control cycle from the application layerdown to the physical hardware layer.

High-level quantum programming languages have beenmore readily studied than supporting compilation frame-works [14]. Programming languages have been intro-duced that are based on C [15] and based on functionallanguages [16, 17]. We argue that instead of inventinga new programming language, a quantum software ar-chitecture should build on an embedded domain-specificlanguage in order to leverage classical language and com-pilation features.

Existing quantum embedded languages include Quip-per [16] and LIQUi |〉[17]. Both are functional languagesand include an underlying compilation framework, allow-ing the representation of quantum algorithms and circuitsat various levels of abstraction. Quipper is embedded inHaskell and allows extensible data types and advancedprogramming constructs. LIQUi |〉 contains a domain-specific language embedded in F# [17]. Compilation isprimarily targeted to backends such as simulators andresource analyzers. In contrast to Quipper, LIQUi |〉 alsofeatures simulators for noise and resource analysis, butneither allows for hardware backends.

ScaffCC is a concrete implementation of a quantum

3

compiler for a C-style language [18]. It compiles to aspecific gate set in the QASM assembly language and en-ables program analysis and low-level optimizations. Ourmethodology differs from the framework followed by Scaf-fCC in that it begins at the top with a high-level em-bedded language instead of a newly defined language, toenable easy programming of quantum algorithms and theability to leverage existing classical language and compi-lation tools. We also automatically translate to hardwareinstructions for specific backend quantum devices. Inaddition, we introduce the compilation and auto-tuningof quantum libraries. This allows programmers to reusesubroutines and automatically determine the best under-lying circuit representations for the target backend, of-fering substantial quantum resource savings.

In addition to our demonstration implementations,our software methodology supports the Quipper andLIQUi |〉 languages as the high-level programminglanguage, and can leverage their simulation and resourceanalysis tools within various layers of the stack. How-ever, our design significantly extends and defines thenecessary components of a complete scalable compilationframework, including details on how to compile, tune,and link libraries, where to map to an explicit hardwarelayout and error correction, and how to map to hardwarecontrols and instructions. We detail the necessary layersof abstraction and the optimizing transformations thatwill ultimately lead to successful compilation of anyquantum algorithm for quantum hardware. We havedesigned our framework explicitly to program andcontrol a quantum computer, no matter its size.

Outline. In Section II, we briefly review quantumcomputation and highlight key characteristics that provecrucial in the design of a software architecture. Weintroduce quantum programs in Section III and definequantum types, quantum gates, quantum libraries, andquantum algorithms. In Section IV, we step througheach compilation layer of the proposed software stack.We begin by discussing the high-level compilers, includ-ing the host language compiler and high-level quantumcompiler, and then describe the low-level compiler,including details on the challenges of fault tolerance andlayout generation for quantum computers. In Section V,we describe the various backends that can be targeted.We highlight the value of auto-tuning of quantumlibraries and optimization of representations in SectionVI and close with a discussion of design implementationsof our stack and future work in Sections VII and VIII.

II. QUANTUM COMPUTING

Quantum computers harness quantum effects in or-der to speed up calculations. Information is stored inquantum bits called qubits and computations are per-formed by applying quantum gates and measurements tothe quantum state of the qubits.

In contrast to its classical counterpart, a qubit maybe in an arbitrary superposition of its two basis stateslabeled |0〉 and |1〉:

α |0〉+ β |1〉 , (1)

with complex amplitudes α, β ∈ C satisfying the normal-ization condition |α|2 + |β|2 = 1. The state of a generaln-qubit system can be an arbitrary superposition over all2n computational basis states, i.e.,

∑q1q2...qn∈{0,1}n

cq1...qn |q1...qn〉 =

2n−1∑i=0

ci |i〉 ,

where we have interpreted the basis state q1...qn as a bi-nary number and replaced it with the corresponding in-teger i. Again, the complex amplitudes ci need to satisfythe normalization condition

∑i |ci|2 = 1.

Information stored in qubits is retrieved by measure-ments, which convert qubits into classical bits. In thecase of measuring all qubits simultaneously, the outcomeis one of the basis states with probability equal the ab-solute value squared of the complex amplitude ci of thatbasis state i. After the measurement, the qubits are nolonger in superposition but in the state determined bythe measurement. When measuring a single qubit in thesuperposition state (1), the outcome is either 0 or 1 withprobability |α|2 or |β|2, respectively, and the wavefunc-tion of the qubit collapses onto the respective basis state(|0〉 or |1〉).

Similar to classical operations, quantum gates can beapplied to qubits to change their state. Multi-qubit gatesare very hard to realize in hardware. However, there existuniversal gate sets consisting of only a handful of one- andtwo-qubit gates, that is, gates applied to just one or twoqubits simultaneously, which can be used to implementany n-qubit quantum gate.

As a consequence of the linearity of quantum mechan-ics, gates are simultaneously applied to all basis statesof a superposition at once – similar to classical SIMDoperations. If, for example, n qubits are in a completesuperposition over all 2n basis states, all possible out-puts of a function f(x) can be calculated using only onefunction call:

f(

2n−1∑i=0

ci |x〉) =

2n−1∑i=0

ci |f(x)〉 .

This phenomenon is called quantum parallelism. How-ever, the outputs of all 2n computations are saved in aquantum superposition. Therefore, simply measuring thequbits will just pick one result at random and is thus nomore powerful than classical computation. To overcomethis, quantum algorithms need to employ sophisticatedreduction schemes, making use of quantum interferenceeffects. For a more thorough introduction to quantumcomputing and a description of the most common gates,see the Appendix.

4

Libraries

- qutypes- qugates- qucontrol- quarithmetic- qumath- qualg

Hostlanguagestandardlibrary

User definedlibraries

usersystemquantum

Figure 3. Libraries available to the quantum program. Thequantum standard library is described in the text. The system(or standard) library is provided by the host language. Theuser may add custom quantum or classical libraries in orderto increase code reuse among developers.

Throughout this paper, we will illustrate quantum cir-cuits through diagrams, where each wire represents aqubit and boxes represent quantum gates. Similar toclassical circuit diagrams, these quantum circuit dia-grams are read from left to right, such that gates at theleft of the circuit are applied before those to the right.

III. QUANTUM PROGRAMS

A quantum program consists of a sequence of classicaland quantum instructions to be executed on hybridsystems consisting of both classical and quantum hard-ware. To lift the quantum parts of the codes to thesame level of abstraction as classical codes, we envisionthree types of libraries that can be leveraged to writequantum/classical hybrid programs using an embeddedDSL (see Figure 3): The classical standard or systemlibrary (from the host language), custom user libraries,and the quantum libraries that we describe below.

Quantum types. In classical computing, one prefersto use abstract types instead of operating at bit-level.Therefore, such types need to be available for quantumprogramming as well. In particular we propose:

• qubit: A quantum bit, which is the basic buildingblock of all quantum types

• qureg: General purpose quantum registers, con-sisting of a fixed or variable number of qubits

• quint: Quantum integer types

• qufixed: Quantum fixed-point types

• qufloat: Quantum floating-point types

Given the extremely limited number of qubits in earlyquantum computers, it is important to provide versionsof qureg, quint, qufixed and qufloat with variablenumbers of bits. The numerical types also provide

1 compute(QFT(x)) // basis change

2 phiAdd(x,a) // a+x in Fourier space

3 uncompute () // applies inverse(QFT)

Listing 1. One possible way of introducing code annotationto help the compiler identify compute-action-uncomputesequences, which can be turned into controlled versions ata much lower cost.

functions and operator overloads, which facilitate theuse of the libraries discussed below. Being aware ofthe limited number of operations that early quantumcomputers will be able to perform, the use of fixed pointarithmetic is crucial and will be more common than theuse of floating point arithmetic.

Quantum gates. Quantum gates can act on oneor multiple qubits. Similar to classical computers, thereare a few standard gates which frequently occur inquantum algorithms. A list of common gates and theirdefinitions is provided in the Appendix.

The quantum gate library features a variety of gateschosen based on various technologies and applications.Gates that are not supported by the hardware must bedecomposed by the compiler.

In contrast to classical gates, many quantum gates,such as rotation gates, have continuous parameters andcannot be executed to arbitrary precision in an actualdevice. Therefore, the programmer needs the option tooverride the conservative default tolerances for individ-ual gates or for an entire algorithm. These tolerancesare then used to optimize hardware control and gatesynthesis. Gate synthesis is the process by which anysingle-qubit quantum gate can be implemented to anydesired precision by finding an efficient sequence ofgates drawn from a discrete set of well-calibrated anderror corrected gates. Efficient methods for such gatesynthesis are well studied [19, 20].

Quantum control flow statements. Quantumalgorithms often contain certain computational patternsthat are not common in classical computing. Makingthese patterns explicit through the use of meta functionsmakes programming easier and facilitates aggressivecode optimization. Among others, the following metaoperations are provided:

• compute/uncompute: As quantum operations mustbe reversible, temporary variables can only be dis-carded after reversing their computation by an un-compute step [21]. That is, ancilla qubits (scratchspace) must be clean at the end of the computa-tion, or before reuse as scratch space. Making thecompute/uncompute pattern explicit by annotat-ing the compute section allows the uncomputationto be done automatically by the compiler. Fur-thermore, various high-level optimizations can beperformed, as discussed below. In certain cases,

5

Rzθ≡

Rz θ2

Rz†θ2

Figure 4. Decomposition of a controlled z-rotation usingCNOTs and single-qubit z-rotations only. Note that a sin-gle control already doubles the number of rotations and in-creases the number of CNOTs by 2. Reducing the numberof controlled gates is essential in order to arrive at efficientquantum code.

U V U†U V U†≡

U V U†

Figure 5. Controlled compute/action/uncompute-sequencescan be achieved by only controlling the middle operation, thussignificantly reducing the number of controlled gates.

the user may override the default uncomputationby an optimized implementation thereof. See List-ing 1 for an example use case.

• control: Conditional code is not straightforwardon quantum computers since the condition variablecan be invoked in a superposition of being bothtrue and false. Similar to classical SIMD codes,one has to use masking and apply the operationsonly to those computational states where a controlqubit is 1. This can be achieved by replacing ev-ery gate by its controlled version. However, thissignificantly increases the number of gates. For ex-ample, as shown in Fig. 4, for simple rotation gatesthe number of gates is four times higher in the con-trolled version. Therefore, it is important to reducethe number of controlled operations by using high-level information such as the compute/uncomputepattern, where the compute and uncompute stepsthemselves do not need to be controlled, as depictedin Fig. 5. The reason is that when the centraloperation V is masked out by the control, thenthe uncompute steps just undoes the compute stepand their combined action is trivial. It is thus notnecessary to control these compute and uncomputesteps, resulting in signifcant savings.

• repeat: A straight-forward generalization of loopsto the quantum domain is not possible due to thefact that the resulting circuit must be able to han-dle a superposition of inputs. Therefore, if the loopcondition is quantum, an upper-bound on the num-ber of iterations must be provided. Furthermore,the entire loop body must be conditioned on a con-tinuation indicator qubit in order to handle caseswhere the loop would terminate before the maximal

Rzθ Rz†θ≡

Rzθ

Figure 6. Providing a quifelse meta function allows thecompiler to reduce the number of gates from ten to three inthis example of a conditional inverse rotation.

number of iterations is reached.

If, on the other hand, the loop condition only de-pends on classical information, such as the out-come of measurements, the handling is simpler. Insuch cases, the code can be optimized by sendingthe entire loop instructions to lower-level classicalhardware, thereby greatly reducing the overhead ofcommunication between the host and the quantumdevice.

• quifelse: This meta function is a generalization ofthe control operation, introduced in order to catchoptimization opportunities, where one operation isperformed if a control qubit is 0 and another oper-ation is performed if it is 1. One common exampleis the conditional inverse for rotating in one direc-tion if the control is 0 and the opposite direction ifit is 1. Instead of performing two controlled rota-tions, which would lead to a total of ten gates (seeFigure 4), this is optimized as shown in Figure 6,resulting in a reduction of the number of rotationsby a factor of four [22].

Quantum arithmetic. The quantum arithmeticlibraries feature optimized low-level implementations ofbasic arithmetic functions such as addition, subtrac-tion, multiplication, fused multiply-add, division, andinverses, which can then be used to implement high-levelfunctions. Upon compilation, the best available imple-mentation can be chosen for the quantum architecturein question using an auto-tuning approach similar toclassical linear algebra packages [23] – see Section VI.

Quantum math library. Building on the quan-tum arithmetic library, the math library providesimplementations of high-level mathematical functionssuch as exponential and arcsine. Again, dependingon the quantum hardware being compiled to, differentapproaches may turn out to be most efficient. Findingthe best one can be achieved using an auto-tuningapproach which takes into account both the compilationof the underlying arithmetic operations and e.g., thetype of series expansion used. In addition, there mightbe precision-dependent implementations, which is espe-cially useful in this case, as qubits are currently a verylimited resource.

Implementing such a quantum math library is a highlynon-trivial endeavor due to the reversibility condition

6

of quantum algorithms. As an example, consider New-ton’s method, which can be used to implement inversesof trigonometric functions in classical computing. Astraight-forward translation of this approach is not fea-sible in the quantum domain due to the fact that themethod needs to succeed for a superposition of values.Therefore, the number of iterations would have to bechosen such that all values converge to the correct resultand simply determining all outcomes scales exponentiallywith the number of qubits.

Similar parallelism and the difficulty arising fromit can also be observed in classical computing whendealing with vector units, which perform single in-structions on multiple data (SIMD). Hence, thesemay serve as a starting point for efficient implemen-tations of mathematical functions on quantum hardware.

Quantum algorithms. This highest level algo-rithms library provides standard quantum subroutinessuch as the quantum phase estimation (QPE), whichestimates eigenvalues of a unitary matrix, the quantumFourier transform (QFT), which performs a Fouriertransformation on the wave function, linear systemsolvers, and other common quantum algorithms. Similarto classical programming, the availability of higher levelalgorithms accelerates quantum programming. Further-more, the compilation process can pick implementationsoptimized for specific target hardware. Providingsuch high-level quantum algorithms will accelerate thedevelopment of new quantum programs.

IV. COMPILATION PROCESS

The translation of a quantum program down to hard-ware instructions is a layered process consisting of severalcompilation and optimization steps. Each compiler gen-erates a quantum intermediate representation (QIR) or– after error correction – a low-level QIR (LLQIR) ofthe original code. The layering allows for a hardware-agnostic implementation of the higher-level compilers,thus increasing code reuse. The overview of the com-pilation process is depicted in Figure 2 and a more de-tailed version, whose individual steps are discussed in thefollowing, is shown in Figure 8.

The stages of compilation will be illustrated using ahigh-level implementation of Shor’s algorithm for fac-toring [6]. While we have implemented demonstrationversions of this architecture and Shor’s algorithm in anumber of programming languages, some of which arediscussed below, we explain the architecture using pseu-docode to highlight the software requirements and notspecific implementations. Listing 2 shows pseudocodeand Fig. 7 the corresponding circuit diagram for an im-plementation similar to that of Ref. [24]. Note that thefinal box represents measurement.

1 ...

2 x = allocateQureg(n, value = 1)

3 ancillas = allocateQureg (2n)

4 Ua(k,x) = a(k)*x mod N

5 CUa(k,c,x) = control(c,Ua(k,x))

6 QPE[CUa] (ancillas , x)

7 m = measure(ancillas)

8 r = continuousFracExpand(m).denom()

9 ...

Listing 2. High-level pseudocode of Shor’s algorithm, whichneeds to be compiled down to a given specific hardware.

2n

n

|0〉

|1〉QPE(cUa)

m

Figure 7. Circuit representation of Shor’s algorithm. Aquantum phase estimation (QPE) is performed using a con-trolled version of the operator Ua, which implements Ua |x〉 =|ax mod N〉. The result of the QPE can then be used to ex-tract the period of the function f(x) = ax mod N and, thus,determine the factors of N .

A. Host language compilation

The first step of the compilation process is carried outby the host language compiler/interpreter, resolving thecontrol statements of the classical code and performingfirst optimizations. It also dispatches quantum state-ments to (potentially backend-dependent) library func-tions. Having the classical compiler do as much as pos-sible keeps the effort of implementing the compilationframework minimal.Shor example: Sending the high-level code in Listing 2

through this compiler results in code similar to what isshown in Listing 3: In this pseudocode example, the re-source allocation (allocateQureg) has been replaced bya member function call of the backend for which the codeis being compiled. The backend may be anything thatfulfills a predefined concept, be it an emulator or an ob-ject which sends hardware instructions to the quantumdevice. Furthermore, the mathematical expression hasbeen resolved to a quantum math function call. Similartransformations have been applied to the QPE-syntaxand measurement, which should be handled by a con-crete backend as well.

B. High-level quantum compiler

Following the host language compiler/interpreter, thequantum part of the code is compiled further using all

7

Quantum program

Host languagecompiler

High-level compiler

Rewriting of n-qubit gates

Library interfaces

Pre-compiledlibraries

Logical layoutgenerator

QEC compiler

Physical layoutgenerator

Library source codes(if available)

Gate synthesis(e.g. of rotations)

Low

-level co

mp

iler

Hardwareconstraints

Gate rewritingstrategies

Meta-instruction optimization strategies

QEC strategies

Hardwareparameters

Mapping to hardware

Hardwareparameters

Gate synthesis strategies

eDSL

QIR

QIR

QIR

QIR

QIR

LLQIR

LLQIR

Layout a

nd

QEC

Linker

QIR

Figure 8. Detailed view of the toolchain: The quantum program written in an embedded domain-specific language (eDSL) istranslated to hardware instructions using a series of compilers, which generate quantum intermediate representations (QIR)and, ultimately, low-level quantum intermediate representations (LLQIR) of the code. As a final step, the LLQIR is translatedto hardware instructions.

8

1 ...

2 x = backend.allocateQureg(n)

3 backend.initialize(x, 1)

4 ancillas = backend.allocateQureg (2n)

5 Ua(k,x) = qmath.axmodN(a(k), x, N)

6 CUa(k,c,x) = control(c, Ua(k,x))

7 qstd.QPE(CUa , ancillas , x)

8 m = backend.measure(ancillas)

9 r = continuousFracExpand(m).denom()

10 ...

Listing 3. High-level pseudocode of Shor’s algorithm aftergoing through the host language compiler.

available information on the high-level structure of thequantum program. This includes both meta instructionreplacement and optimization.

Replacements: Meta functions and library calls are re-placed by their implementation, where available. For ex-ample, the uncompute statement applies the inverse ofthe previous compute-section. Another example is thecontrol instruction, which may be applied to individualgates or entire algorithms. Since libraries may providecontrolled versions of implemented functions, the com-piler chooses between either directly calling a controlledversion of the function, annotating the library call with acontrol-flag that will be resolved in later stages, or com-piling a controlled version of the function if the sourcecode is available. In the latter case, the compiler makesuse of all meta-information available (e.g., that the com-pute/uncompute sections do not need to be controlled) inorder to make the resulting code as efficient as possible.

Optimizations: After all meta functions have been han-dled, the compiler executes a series of optimization stepsin order to improve code efficiency. For example, multiplerotations carried out on the same qubit can be combinedin a quantum analog of constant folding, which would bemuch harder after rotation gates have been synthesizedinto fundamental gates further down the stack.

Shor example (continued): Applying these first trans-formations to the high-level circuit of Shor’s algorithm,which is depicted in Figure 7, yields the circuit in Figure 9at first, where the library implementation of the quan-tum phase estimation has been inlined. If the user wereto provide a quantum register whose size is incompatiblewith the desired precision, an iterative phase estimationwould be chosen instead of the standard QPE.

Now, the compiler proceeds by resolving the controlson the function Ua, making use of the structure of thecomputation (e.g., not controlling basis changes). In ad-dition, it uses the library implementation of the inversequantum Fourier transform (QFT†), which itself mightrequire optimization. A possible library implementationfor a 3-qubit QFT† is depicted in Figure 10.

This entire process is iterated until there are no librarycalls left for which the source code is available. An ex-cerpt of the quantum intermediate representation afterhaving completed this stage is depicted in Listing 5.

|0〉

|0〉

|0〉

|1〉

H

......

H

H

Uan

Ua2 Ua22n−1...

...

...

...

QFT†

Figure 9. Shor circuit where the library implementation ofQPE has been inlined. The inverse quantum Fourier trans-form (QFT†), which is applied to the 2n qubits at the top, isanother library call yet to be handled by the compiler.

H

R−π2

H

R−π4

R−π2

H

Figure 10. Possible library implementation of a 3-qubit in-verse quantum Fourier transform.

C. Low-level quantum compiler

After the high-level compilation stage, the code con-sists of quantum gates, inlined library functions, and li-brary calls to be resolved later. The task of the low-

1 ...

2 /* QPE on modular multiplier.

3 Do repeated modular addition and

4 shift on x, store result into b */

5 // begin modular Draper -addition

6 ccphiadd(qpe_ctrl , x[i], a, b)

7 phisub(N, b)

8 iQFT(b)

9 backend.apply(CNOT , b[end], ancilla)

10 QFT(b)

11 cphiadd(ancilla , N, b)

12 ccphisub(qpe_ctrl , x[i], a, b)

13 iQFT(b)

14 backend.apply(NOT , b[end])

15 backend.apply(CNOT , b[end], ancilla)

16 backend.apply(NOT , b[end])

17 QFT(b)

18 ccphiadd(qpe_ctrl , x[i], a, b)

19 ...

20 m = backend.measure(0, ..., 2n-1)

21 ...

Listing 4. Excerpt of a quantum intermediate representationof Shor’s algorithm after a few iterations of the high-levelcompilation.

9

1 ...

2 // begin QPE

3 ...

4 // begin inverse QFT

5 backend.apply(H, 0)

6 backend.apply(CR(-pi/2), 0, 1)

7 backend.apply(H, 1)

8 backend.apply(CR(-pi/4), 0, 2)

9 ...

10 m = backend.measure(0, ..., 2n-1)

11 ...

Listing 5. Excerpt of a quantum intermediate representationof Shor’s algorithm after the final iteration of the high-levelcompilation.

level compiler is to translate all quantum gates into se-quences of gates from a discrete, technology-dependentset of quantum gates. The concrete structure of thisset depends on both the hardware and the chosen error-correction strategy.

Rewriting and synthesis of gates: Each quantum gatenow has to be synthesized from a smaller, hardware-specific set of gates. For example, multi-qubit gates willbe synthesized from one-qubit gates and a technology-specific two-qubit gate, similar to what is depicted inFigure 4. Then, further hardware-specific rewriting rulesare applied, including the decomposition of single-qubitoperations into sequences of gates from a technology-dependent set, which could include the so-called T,H, and S gates. This gate synthesis can be achieveddeterministically [20] or using non-deterministic algo-rithms [19].

Optimizations: As a final step of the low-level com-pilation phase, local optimization rules can be appliedwith the goal of further reducing the number of expen-sive operations, such as the number of T gates on certainarchitectures, see, e.g., Ref. [25].

Shor example (continued): The rewriting and synthe-sis of gates can be observed in our Shor example, wherethis decomposition is applied to the rotation gates thatarise from the inverse quantum Fourier transform. Theconditional phase shift of −π2 can be rewritten in termsof T, S, and CNOT gates, as shown in Listing 6. Therotations required for the −π4 controlled phase shift, onthe other hand, need to be approximated using one ofthe approaches mentioned above. Considering that therespective sequences for a rotation gate with an angleθ = −π8 isHTSHTSHTSHTHTSHTSHTSHTHTSHTHTSHTHTSHTSHTHTHTSHTSHTHTSHTHTSHTHTHTHTSHTSHTSHTHTSHTSHTSHTHTSHTHTHTHTSHTHTHTSHTHTHTHTSHTSHTSHTHTSHTSHTHTSHTHTSHTHTSHTHTSHTSHTHTSHTHTSHTSHTSHTSHTHTHTSHTHTSHTHTHTHTSHTHTHTHTHTHTSHTSHTSHTHTSHTSHTHTSHTSHTHTHTSHTSHTHTHTSHTHTHSSfor a tolerance of 10−10 and

1 ...

2 // begin inverse QFT

3 backend.apply(H, 0)

4 // decompose Rz(-pi/4) (trivial)

5 backend.apply(T, 1)

6 backend.apply(S, 1)

7 backend.apply(S, 1)

8 backend.apply(S, 1)

9 backend.apply(CNOT , 0, 1)

10 backend.apply(T, 1)

11 backend.apply(CNOT , 0, 1)

12 backend.apply(Tdagger , 0)

13 backend.apply(H, 1)

14 // decompose Rz(-pi/8)

15 backend.apply(H, 2)

16 backend.apply(T, 2)

17 backend.apply(S, 2)

18 backend.apply(H, 2)

19 backend.apply(T, 2)

20 backend.apply(S, 2)

21 ...

Listing 6. Part of the quantum intermediate representationof Shor’s algorithm after the low-level compilation. Thecontrolled rotation gates have been decomposed into CNOT,S, H, and T gates.

HTHTSHTSHTSHTSHTHTSHTHTHTSHTHTSHTHTHTSHTSHTSHTSHTSHTSHTSHTSHTSHTHTSHTHTSHTHTHTSHTSHTSHTHTHTHTSHTSHTHTSHXfor a tolerance of 10−4, one immediately sees the trade-offbetween runtime and accuracy.

In the end, the quantum intermediate representationconsists of code similar to the one shown in Listing 6.

D. Logical layout generator and optimizer

Following the low-level compilers, we have to assignqubit variables to logical qubits similar to how variablesare assigned to registers in classical computers.

The code coming from the low-level compilers still con-tains calls to library functions such as arithmetic opera-tions. While a large-scale quantum computer might havededicated qubits and gates for certain functions similar tothe arithmetic and logical units in modern CPUs, earlyquantum computers will only have a small number ofgeneral purpose qubits and gates. Hence, calls to pre-compiled libraries now need to be replaced by the corre-sponding code, which has been optimized for the specifichardware. At this point, the logical layout can be done.

So far we have only talked about qubits in an abstractway. We now need to introduce the notion of three dif-ferent types of qubits: logical qubit, physical qubit andhardware qubit.Logical qubits are qubits used in the specification of the

algorithm. They are perfect in the sense that they do notrepresent any hardware-level implementation and hencedo not suffer from any noise. Similarly, logical-level gate

10

operations are also perfect. They occur at the algorith-mic level of specification. Until this point, qubits alwaysreferred to such logical qubits. The logical level is thelevel of abstraction most suitable for high-level program-ming.

Physical qubits are actual noisy qubits that decohereand lose their quantum properties after a short time –too short for most quantum programs. To extend theirlifetime, a large number of physical qubits can be com-bined with an error correction scheme to represent onelogical qubit.

Hardware qubits are the physical qubits constrained toa specific quantum device chip. They each have a uniqueaddress.

During the logical layout step, we map quantum vari-ables to specific logical qubits, taking into account local-ity, available operations, timing, and parallelism. Local-ity of logical qubits is important as it may only be possi-ble to apply gates between neighboring qubits. Hence, iftwo logical qubits are far apart from each other, one hasto rely on expensive teleportation or swapping of logicalqubits. In this step, timing must also be introduced forparallel code execution, since different operations mayhave different durations that have to be taken into ac-count for parallel scheduling of operations.

Note that early quantum computers will not haveenough qubits to perform quantum error correction. Inthis case, we treat physical as logical qubits and skip thenext error correction step.

E. Quantum error correction (QEC)

Unlike classical computers, quantum computers sufferreadily from noise on very short time scale and requiresubstantial overhead in both additional qubits and quan-tum gates to maintain a fault-tolerant and reliable com-putation. Quantum error correction protects a logicalqubit through redundancy, which is similar in nature toa classical repetition code, where a bit of information iscopied into several bits and the information is decoded bytaking a majority vote over the copies. If the error rateon a given bit is low enough, that is, below a threshold,then the information will be protected.

Quantum information cannot be cloned due to the NoCloning Theorem. However, quantum circuits exist todistribute the information of a logical qubit across manyphysical qubits and to extract information on the types oferrors through measurement. QEC protocols make use ofthis fact and allow quantum information to be protectedby the use of quantum encoding and decoding circuits.Ultimately, in any software-level QEC protocol, a logicalqubit is encoded into a number of physical qubits, wherethe number depends on the error rates of the physicalquantum device and the protection capacity, called thedistance, of the selected quantum error-correcting code.To date, one of the best QEC codes is the so-called sur-face code, which can protect against error rates of up to

1% [26].

A software architecture must handle the mapping fromlogical qubit to the underlying physical qubits’ represen-tation. Performing this mapping requires knowledge ofthe number of physical qubits required to represent theone (or more) logical qubit(s), as well as the constraintsof the physical mapping. Each logical quantum gate op-eration must also be encoded; the mapping must replaceeach logical operation by the encoded fault-tolerant oper-ation for the given code. The overlaying of quantum errorcorrection on the logical computation is a non-trivial lay-out and scheduling task and will require substantial opti-mization routines to minimize resource overheads. Notethat in encoding each logical qubit and logical gate, asubstantial number of physical qubits and computationtime is required.

A QEC code also requires a decoding procedure [27,28]. While classically one can decode the repetition codevery simply with a majority vote, most quantum de-coding algorithms require more substantial computation.The process of decoding is in fact classical and occurs ona classical processor.

The choice of QEC protocol depends on the hardwarequbit properties, the fidelity of the hardware’s quantumgates, and the number of logical gates in the quantumalgorithm. Thus, it will be crucial to have a QEC li-brary available in order to select the QEC protocol thatminimizes the overall resources required to complete thegiven quantum algorithm. It will also be important tohave very fast feedback and control between the classicaland quantum hardware. The classical processor perform-ing the decoding must be fast enough to maintain pacewith the quantum computer and decode errors at speed,so as to prevent the logical qubits from becoming toonoisy.

F. Physical layout generator and optimizer

At this level, the physical qubits are mapped to actualhardware qubits. This mapping may be straightforwardif the hardware layout is built with a specific error cor-rection scheme in mind. In addition, some of the gateoperations might require adjustments.

G. Mapping to hardware

The final step is the mapping of physical gate opera-tions to hardware control of the specific device. For ex-ample, a hardware backend for superconducting qubitsmay map a native X gate to a function call of an arbi-trary wave form generator which will apply a microwavepulse corresponding to an X gate on this qubit.

11

V. BACKENDS

Our architecture was specifically designed to support avariety of different backends, not just hardware backendsbut also software backends, e.g., simulators, emulators,and resource counters.

Hardware backends. There are many differentcompeting technologies for quantum computer, includ-ing superconducting circuits, topological qubits, iontraps, spin qubits, and photonic qubits, just to name afew. Each of these technologies will have a unique set ofnative gate operations, and additionally each device aunique control interface.

Simulators. Simulators play an important role inthe development of quantum computers. At the lowestlevel, a simulator can be used to simulate the operationof the native hardware gates or at a higher level oflogical qubits. Simulators can include noise for differenthardware technologies, which makes it possible to studyits effects on the performance of quantum algorithms,especially on near-term quantum computers that willnot have logical qubits yet. The size of the complexvalued wave function representing the state of a quantumcomputer with N qubits grows as 2N . Since a gateoperation can be implemented by a sparse matrix-vectormultiplication such a simulation of a quantum computeris a sequence of matrix vector multiplications. Withcurrent supercomputers, around 40-50 qubits can besimulated.

Some gate operations, such as swap gates, may besimulated more efficiently by simply switching theindices of the qubit ordering rather than changing theexponentially large wave function.

Emulators. More efficient simulation is possibleby emulating quantum computers at a higher level ofabstraction. Libraries may provide a way of emulatingthe functions they implement, which the emulator willuse instead of performing a sequence of many gateoperations. In the following, we list a few key example:

• Mathematical functions, such as the modular ex-ponentiation required for Shor’s algorithm, do notneed to be simulated through a large number of re-versible gate operations, but can be emulated moreefficiently by simply calling classical mathemati-cal operations on each of the computational basisstates.

• Quantum Fourier transforms can be emulated sim-ilarly by performing a fast Fourier transform on thewave function.

• Repeated application of the same gate sequence fora large number of times n may be optimized bybuilding up a dense matrix representation U of theactions of these gates and then performing repeated

squaring to calculate Un. Whether this is more ef-ficient depends on the tradeoff between doing O(n)sparse matrix-vector operations or O(log n) densematrix-matrix operations.

• Similarly, a quantum phase estimation, which es-sentially computes eigenvalues and eigenvectors ofa unitary matrix, may be emulated more efficientlyby diagonalizing the matrix for cases where thenumber of qubits is small.

• When encountering measurements, an emulatorcan record the full expected distribution instead ofsampling from it by performing random choices, asit is done in simulation.

Finally, oracular algorithms where no concrete quan-tum implementation of the oracle exists can still beemulated by providing a classical emulation of the oracle.

Resource counters. A resource counter keepstrack of the number of qubits and gates that a certain al-gorithm would use when executed on a specific quantumcomputer. This is important information for designingand improving quantum algorithms. It is not sufficientthat the asymptotic scaling of a quantum algorithm isbetter than that of the best known classical algorithm,but also that the crossover point in absolute time issmall enough [29]. Estimating resources is importantto guide optimization efforts and to identify realisticapplications of quantum computers.

VI. OPTIMIZATION AND AUTO-TUNING OFLIBRARIES

In order to reduce the cost of quantum library func-tions, an auto-tuning approach can be used. This issimilar to the classical case, where linear algebra pack-ages such as ATLAS [23] automatically determine opti-mal tuning parameters. This is achieved by compilingdifferent code versions and choosing the one yielding thebest runtime. Due to the immense cost of optimizationand auto-tuning, these should be done at the level of li-brary functions, which are pre-compiled. This allows forreasonable compilation times of quantum programs thatmake use of such highly-tuned library functions.

Yet, trivially applying this auto-tuning approach is notfeasible, given the vast amount of possible parametersin need of tuning. This can be seen when consideringthe addition operation as an example: There is a muchwider variety of different adders in quantum than thereis in classical computing. Some are classical addition al-gorithms that have been generalized to the quantum do-main, such as Cuccaro et al.’s Ripple-Carry addition [30].Others are purely quantum, such as Draper’s addition inFourier space [31]. Which adder to use on which architec-ture depends on much more than just the operation countand the type of gates: In-place algorithms are favorable

12

in terms of space constraints, which are much more se-vere in quantum computing. Yet, uncomputing inter-mediate results becomes more time-consuming in thatcase. Furthermore, good trade-offs between uncomput-ing intermediate results early and requiring more qubitsmust be found, since those temporary results will haveto be recomputed in order to clear ancilla registers. Re-cently, this issue has been addressed by a compiler calledRevs [32] which is able to reduce space complexity by afactor of 4 for large functions such as e.g., SHA-2 whencompared to Bennett’s method [21]. Such approaches canbe used to generate code for low- and high-level math-ematical functions for which no hand-optimized imple-mentations are available.

VII. DEMONSTRATION IMPLEMENTATIONS

We have implemented a simplified version of the soft-ware architecture described above in several languages fordemonstration purposes. Our implementation in Pythonuses runtime dispatch of high-level functions to libraryimplementations, and then to backend-specific compila-tion of gates into hardware gates and the dispatch to asimulator or actual quantum hardware. The second im-plementation in C++ uses template meta programmingfor compile-time dispatch to the appropriate implemen-tation for the backends (resource estimator, simulator,emulator hardware calls), combined with additional op-timizations performed on gate sequences at runtime.

Carrying out the quantum compilation at runtime(e.g., in Python) or at compile-time by the host languagecompiler (e.g., in C++) are only two options. Other pos-sible approaches are to perform the quantum compila-tion by post-processing an intermediate representationof the program produced by the host language compiler,for example by transforming the LLVM representationof a C++ program or the MSIL output of a C# or F#compiler [33].

VIII. SUMMARY

With the rapid development of small-scale quantumcomputers, it is necessary to develop a matching soft-ware infrastructures that goes beyond the simulators thathave been developed so far. Our approach to a quantumsoftware architecture begins with an embedded domain-specific language by representing quantum types and op-erations through types and functions existing in a classi-cal host language. This leverages the capabilities of thehost language while allowing substantial user-driven de-velopment. It also underlines the roles of quantum com-puters, namely as special purpose accelerators for exist-ing classical codes. By using an eDSL, we do not haveto port the classical functionality to a newly developedquantum language.

In the near term, a quantum software architecture willallow the control of small-scale quantum devices and en-able the testing, design, and development of componentson both the hardware and software side. We will wit-ness more rapid innovations through the use of a commonplatform among quantum theorists, engineers, and exper-imentalists. We believe that an instantiation of our soft-ware methodology will enable demonstrations of quan-tum programs for a variety of different devices in thevery near future.

A high-level programming environment with optimizedquantum emulation backends is important for the devel-opment of quantum algorithms and programs for futurequantum computers. This will allow to demonstrate theirusefulness and motivate further development of quantumhardware and software. In future work, we look forwardto developing the various components and seeing a rev-olution in computation through scalable quantum com-puters.

ACKNOWLEDGMENTS

We thank Alan Geller, Alexandr Kosenkov, SvyatoslavSavenko, and Dave Wecker for useful discussions and weacknowledge support by the Swiss National Science Foun-dation, the Swiss National Competence Center for Re-search and hospitality by the Aspen Center for Physics,supported by NSF grant #PHY-1066293.

[1] RichardP. Feynman, “Simulating physics with comput-ers,” International Journal of Theoretical Physics 21,467–488 (1982).

[2] Rolando Somma, Gerardo Ortiz, James E Gubernatis,Emanuel Knill, and Raymond Laflamme, “Simulatingphysical phenomena by quantum networks,” Physical Re-view A 65, 042323 (2002).

[3] Alan Aspuru-Guzik, Anthony D Dutoi, Peter J Love,and Martin Head-Gordon, “Simulated quantum compu-tation of molecular energies,” Science 309, 1704–1707

(2005).[4] David Poulin, Matthew B Hastings, Dave Wecker,

Nathan Wiebe, Andrew C Doherty, and MatthiasTroyer, “The trotter step size required for accurate quan-tum simulation of quantum chemistry,” arXiv preprintarXiv:1406.4920 (2014).

[5] Bela Bauer, Dave Wecker, Andrew J Millis, Matthew BHastings, and Matthias Troyer, “Hybrid quantum-classical approach to correlated materials,” arXivpreprint arXiv:1510.03859 (2015).

13

[6] Peter W Shor, “Algorithms for quantum computation:Discrete logarithms and factoring,” in Foundations ofComputer Science, 1994 Proceedings., 35th Annual Sym-posium on (IEEE, 1994) pp. 124–134.

[7] Seth Lloyd, Masoud Mohseni, and Patrick Reben-trost, “Quantum algorithms for supervised and unsuper-vised machine learning,” arXiv preprint arXiv:1307.0411(2013).

[8] Patrick Rebentrost, Masoud Mohseni, and Seth Lloyd,“Quantum support vector machine for big data classifi-cation,” Physical review letters 113, 130503 (2014).

[9] Nathan Wiebe, Ashish Kapoor, and Krysta MSvore, “Quantum deep learning,” arXiv preprintarXiv:1412.3489 (2014).

[10] Nathan Wiebe, Ashish Kapoor, and Krysta Svore,“Quantum nearest-neighbor algorithms for machinelearning,” arXiv preprint arXiv:1401.2142 (2014).

[11] Stephen Jordan, “Quantum algorithm zoo,” (2011),http://math.nist.gov/quantum/zoo/.

[12] Krysta M Svore, Alfred V Aho, Andrew W Cross, IsaacChuang, and Igor L Markov, “A layered software archi-tecture for quantum computing design tools,” Computer, 74–83 (2006).

[13] N Cody Jones, Rodney Van Meter, Austin G Fowler, Pe-ter L McMahon, Jungsang Kim, Thaddeus D Ladd, andYoshihisa Yamamoto, “Layered architecture for quantumcomputing,” Physical Review X 2, 031007 (2012).

[14] Simon J Gay, “Quantum programming languages: Sur-vey and bibliography,” Mathematical Structures in Com-puter Science 16, 581–600 (2006).

[15] Bernhard Omer, “A procedural formalism for quantumcomputing,” Citeseer (1998).

[16] Alexander S Green, Peter LeFanu Lumsdaine, Neil JRoss, Peter Selinger, and Benoıt Valiron, “Quipper: ascalable quantum programming language,” in ACM SIG-PLAN Notices, Vol. 48 (ACM, 2013) pp. 333–342.

[17] Dave Wecker and Krysta M Svore, “LIQUi |〉: A soft-ware design architecture and domain-specific languagefor quantum computing,” arXiv:1402.4467 (2014).

[18] Ali JavadiAbhari, Shruti Patil, Daniel Kudrow, JeffHeckey, Alexey Lvov, Frederic T Chong, and MargaretMartonosi, “ScaffCC: A framework for compilation andanalysis of quantum computing programs,” in Proceed-ings of the 11th ACM Conference on Computing Fron-tiers (ACM, 2014) p. 1.

[19] Alex Bocharov, Martin Roetteler, and Krysta M Svore,“Efficient synthesis of probabilistic quantum circuits withfallback,” Physical Review A 91, 052317 (2015).

[20] Neil J Ross and Peter Selinger, “Optimal ancilla-free clif-ford+ t approximation of z-rotations,” arXiv:1403.2975(2014).

[21] CH Bennett, “Logical reversibility of computation,”Maxwells Demon. Entropy, Information, Computing ,197–204 (1973).

[22] Dave Wecker, Matthew B Hastings, Nathan Wiebe,Bryan K Clark, Chetan Nayak, and Matthias Troyer,“Solving strongly correlated electron models on a quan-tum computer,” Physical Review A 92, 062318 (2015).

[23] R Clint Whaley and Jack J Dongarra, “Automaticallytuned linear algebra software,” in Proceedings of the 1998ACM/IEEE conference on Supercomputing (IEEE Com-puter Society, 1998) pp. 1–27.

[24] Stephane Beauregard, “Circuit for shor’s algorithm using

2n+ 3 qubits,” arXiv preprint quant-ph/0205095 (2002).[25] Dmitri Maslov, Gerhard W Dueck, D Michael Miller,

and Camille Negrevergne, “Quantum circuit simplifica-tion and level compaction,” Computer-Aided Design ofIntegrated Circuits and Systems, IEEE Transactions on27, 436–444 (2008).

[26] Austin G Fowler, Adam C Whiteside, and Lloyd CLHollenberg, “Towards practical classical processing forthe surface code,” Physical review letters 108, 180501(2012).

[27] Austin G Fowler, Matteo Mariantoni, John M Martinis,and Andrew N Cleland, “Surface codes: Towards practi-cal large-scale quantum computation,” Physical ReviewA 86, 032324 (2012).

[28] Jack Edmonds, “Paths, trees, and flowers,” CanadianJournal of mathematics 17, 449–467 (1965).

[29] Dave Wecker, Bela Bauer, Bryan K. Clark, Matthew B.Hastings, and Matthias Troyer, “Gate-count estimatesfor performing quantum chemistry on small quantumcomputers,” Phys. Rev. A 90, 022305 (2014).

[30] Steven A Cuccaro, Thomas G Draper, Samuel A Kutin,and David Petrie Moulton, “A new quantum ripple-carry addition circuit,” arXiv preprint quant-ph/0410184(2004).

[31] Thomas G Draper, “Addition on a quantum computer,”arXiv preprint quant-ph/0008033 (2000).

[32] Alex Parent, Martin Roetteler, and Krysta M Svore,“Reversible circuit compilation with space constraints,”arXiv:1510.00377 (2015).

[33] A. Geller, “Software tool chains for quantum computing,”(2016), scaleQIT Conference, Delft, January 29, 2016.

Appendix A: Appendix

The state of one qubit can be represented using a two-dimensional complex vector as follows

α |0〉+ β |1〉 = α

(10

)+ β

(01

)=

(αβ

),

where |0〉 and |1〉 are the basis states of a two-dimensionalcomplex vector space and α, β ∈ C are complex ampli-tudes satisfying the normalization condition, i.e. |α|2 +|β|2 = 1. This condition ensures that the total probabil-ity of measurement outcomes sums up to 1.

For two qubits, the basis states are all possible config-urations of two classical bits, i.e. |00〉 , |01〉 , |10〉 , |11〉. Ageneral two-qubit state can be written in vector notationas

α |00〉+ β |01〉+ γ |10〉+ δ |11〉

= α

1000

+ β

0100

+ γ

0010

+ δ

0001

=

αβγδ

,

where α, β, γ, δ ∈ C. More generally, the quantum stateof n qubits can be represented by a complex vector oflength 2n.

A unitary quantum operation on n qubits can bewritten as a matrix of dimension 2n×2n. A few common

14

|α〉

|β〉

Figure 11. Quantum circuit representation of the example.

examples of one- and two-qubit gates can be found inTable I.

Example. Suppose two qubits are in single-qubitstates |α〉 := α0 |0〉 + α1 |1〉 and |β〉 := β0 |0〉 + β1 |1〉,the state of the entire system is the tensor productof the two individual states, which corresponds to theKronecker product in vector notation, i.e.

(α0

α1

)⊗(β0β1

)=

α0β0α0β1α1β0α1β1

. (A1)

Equivalently, this can be written as

α0β0 |00〉+ α0β1 |01〉+ α1β0 |10〉+ α1β1 |11〉 .

As a side note: Not all two-qubit states can be written as

a product of single-qubit states. Such states are said to beentangled and play a crucial role in quantum computing.

The result of applying a CNOT gate to these twoqubits can be obtained by a matrix-vector multiplica-tion of the CNOT gate matrix in Table I with the statevector in (A1):1 0 0 0

0 1 0 00 0 0 10 0 1 0

·α0β0α0β1α1β0α1β1

=

α0β0α0β1α1β1α1β0

Next, we want to apply a NOT gate to the first qubitand leave the second one unchanged. This can be accom-plished by multiplying the state vector with the matrix

X ⊗ 12 =

(0 11 0

)⊗(

1 00 1

)=

0 0 1 00 0 0 11 0 0 00 1 0 0

,

which yields0 0 1 00 0 0 11 0 0 00 1 0 0

·α0β0α0β1α1β1α1β0

=

α1β1α1β0α0β0α0β1

.

The corresponding circuit diagram is depicted in Fig-ure 11.

15

Gate Matrix Symbol

NOT or Xgate

(0 11 0

)

Y gate

(0 −ii 0

)Y

Z gate

(1 00 −1

)Z

Hadamardgate

1√2

(1 11 −1

)H

S gate

(1 00 i

)S

T gate

(1 0

0 eiπ/4

)T

Rotation-Zgate

(e−iθ/2 0

0 eiθ/2

)Rzθ

ControlledNOT

(CNOT)

1 0 0 00 1 0 00 0 0 10 0 1 0

Table I. Standard quantum gates with their correspondingmatrices and symbols.