3.2. A graph-based Internal Representations
Before jumping into what merging with classical compiler technologies means for quantum program optimisation, let us address the program representation challenge that we touched on in the previous chapter.
Quantum circuits are very limited in their expressiveness: they are well suited to present sequences of purely quantum operations as well as how the computation is parallelised across qubits, but they quickly become limiting once both quantum and classical data types are mixed and any type of control flow (conditionals, loops, function calls, etc.) is introduced.
How users express programs in the front end has deep implications on the kind of computations that the compiler must be capable of reasoning about – and hence on the architecture of the compiler itself. The great merging of classical and quantum compilers is the perfect opportunity to reconcile program representations and to integrate the learnings from decades of classical programming languages research into quantum computing.
There have been several trailblazing initiatives to create quantum programming languages, such as QCL Ömer, 2000. 2000. Quantum Programming in QCL. (January 2000). Retrieved from http://tph.tuwien.ac.at/ oemer/doc/quprog.pdf, Q# Micros., 2024. 2024. Introduction to the quantum programming language Q#. Retrieved on 31/12/2024 from https://learn.microsoft.com/en-us/azure/quantum/qsharp-overview and Silq Bichsel, 2020. 2020. Silq: a high-level quantum language with safe uncomputation and intuitive semantics. In Proceedings of the 41st ACM SIGPLAN Conference on Programming Language Design and Implementation, June 2020. ACM, 286--300. doi: 10.1145/3385412.3386007. It has to be said, however, that their impact and adoption in the quantum ecosystem has so far remained limited, overshadowed by the popularity of python-based APIs for quantum circuit-based representations, as offered by Qiskit Javadi., 2024. 2024. Quantum computing with Qiskit. arXiv: 2405.08810 [quant-ph], Pennylane Bergho., 2022. 2022. PennyLane: Automatic differentiation of hybrid quantum-classical computations. arXiv: 1811.04968 [quant-ph] and Cirq Cirq D., 2024. 2024. Cirq. There is as a result a justified dose of scepticism in the quantum community on how well the ideas from classical programming really translate to quantum.
It is thus all the more notable that we are seeing a new generation of quantum programming tooling being developed Koch, 2024. 2024. GUPPY: Pythonic Quantum-Classical Programming. In Informal Proceedings of the Fourth International Workshop on Programming Languages for Quantum Computing (PLanQC '24), January 2024 Ittah, 2024. 2024. Catalyst: a Python JIT compiler for auto-differentiable hybrid quantum programs. Journal of Open Source Software 9, 99 (July 2024, 6720). doi: 10.21105/joss.06720 CUDA-Q., 2024. 2024. CUDA-Q Documentation. Retrieved on 31/12/24 from https://nvidia.github.io/cuda-quantum/latest/index.html, driven by the need to write more expressive programs for the improving hardware (as we have been discussing), as well as for performance reasons, to scale quantum compilation to large scale Ittah, 2022. 2022. QIRO: A Static Single Assignment-based Quantum Program Representation for Optimization. ACM Transactions on Quantum Computing 3, 3 (June 2022, 1--32). doi: 10.1145/3491247, accelerate quantum simulations Ittah, 2024. 2024. Catalyst: a Python JIT compiler for auto-differentiable hybrid quantum programs. Journal of Open Source Software 9, 99 (July 2024, 6720). doi: 10.21105/joss.06720 and integrate with classical high performance computing (HPC) NVIDIA, 2024. 2024. NVIDIA Accelerates Quantum Computing Centers Worldwide With CUDA-Q Platform. Retrieved on 31/12/2 from https://investor.nvidia.com/news/press-release-details/2024/NVIDIA-Accelerates-Quantum-Computing-Centers-Worldwide-With-CUDA-Q-Platform/default.aspx.
The history of programming is first and foremost a masterclass in constructing abstractions. Many of the higher level primitives, that have proven invaluable classically, solve problems that we expect to encounter very soon in our hybrid programs – when we have not already. Examples include
- structured control flow to simplify reasoning about branching in quantum classical hybrid programs,
- type systems to encode program logic and catch errors at compile time – this is particularly important for quantum programs as there is no graceful way of handling runtime errors on quantum hardware: by the time the error has been propagated to the caller, all quantum data stored on qubits is probably corrupted and lost,
- memory management such as reference counting and data ownership models. Current hardware follows a static memory model, in which the number of available qubits is fixed and every operation acts on a set of qubits assigned at compile time. This becomes impossible to keep track of in instances such as qubit allocations within loops with an unknown number of iterations at compile time. It thus becomes necessary to manage qubits dynamically, just like classical memory.
To facilitate such a large swath of abstractions, the first step quantum compilers must take is to make a distinction between the language frontend and the internal representation (IR) that the compiler uses to reason about the program and perform optimisations. Today in most frameworks, the frontend and the IR are one and the same: the user is given an API that can be used to create and mutate quantum circuits, which is the same data structure the compiler leverages and transforms to produce (another) circuit, which is in turn sent to and executed on hardware or a simulator – it is circuits all the way down!
LLVM and MLIR #
The classical compilation community has found great advantages in sharing a common standardised IR format. Indeed, whilst the exact syntax and constructs vary from language to language, and whilst, at the other end of the compiler stack, the specific assembly instructions that are emitted differ between hardare targets, much of the compiler middleware can be broadly shared between use cases.
This gave rise to the LLVM Lattner, 2004. 2004. LLVM: A compilation framework for lifelong program analysis & transformation. In International Symposium on Code Generation and Optimization, 2004. CGO 2004.. IEEE, 75--86. doi: 10.1109/CGO.2004.1281665, and more recently, the MLIR Lattner, 2021. 2021. MLIR: Scaling Compiler Infrastructure for Domain Specific Computation. In 2021 IEEE/ACM International Symposium on Code Generation and Optimization (CGO), February 2021. IEEE, 2--14. doi: 10.1109/CGO51591.2021.9370308 projects, which provide common compiler IRs, along with all the infrastructure compilers typically require: IR transformation tooling, translation into hardware-specific assembly, efficient serialisations, in-memory formats etc.
The idea of adopting LLVM for quantum was championed by QIR QIR Al., 2021. 2021. QIR Specification v0.1. Retrieved on 31/12/24 from https://www.qir-alliance.org/, a standard introducing quantum primitives into the LLVM IR. This was subsequently adopted by many quantum hardware providers for its superior expressive power compared to circuit-based formats QIR Al., 2023. 2023. NVIDIA Joins the QIR Alliance as the Effort Enters Year Two. Retrieved on 02/01/2025 from https://www.qir-alliance.org/posts/year_one_in_review/. Building on top of QIR, an IR specifically for quantum-classical programs was proposed in Mark K., 2025. 2025. HUGR: A Quantum-Classical Intermediate Representation. In Fifth International Workshop on Programming Languages for Quantum Computing (PLanQC 2025), with additional soundness guarantees based among others on the no-cloning principle of quantum information. In parallel, projects with similar aims have also emerged McCask., 2021. 2021. A MLIR Dialect for Quantum Assembly Languages. In 2021 IEEE International Conference on Quantum Computing and Engineering (QCE), October 2021. IEEE. doi: 10.1109/QCE52317.2021.00043 Ittah, 2022. 2022. QIRO: A Static Single Assignment-based Quantum Program Representation for Optimization. ACM Transactions on Quantum Computing 3, 3 (June 2022, 1--32). doi: 10.1145/3491247 that make use of the full MLIR and LLVM toolchain.