Unitary Fund

Because evolution is unitary.

A Bird’s-Eye View of Upcoming System-Level Quantum-Classical Compilers

Alex McCaskey

As quantum computers mature, software systems for compilation and control will necessarily need to improve in order to enable the full performant capabilities of a heterogeneous quantum-classical compute node. We envision the need for system-level compiler toolchains akin to those we have today for classical computing — extensible, modular systems with unified intermediate representations that enable a wide array of optimization and code-generation techniques. What is the current state-of-the-art for system-level quantum compiler technologies today, and how is the quantum computer science community organizing to deploy these novel, next-generation software systems? In this blog post, I hope to answer that question and specifically highlight two recent developments that leverage the software infrastructure from the LLVM ecosystem — the Quantum Intermediate Representation (QIR) and the MLIR Quantum Dialect. These two projects represent the latest with respect to deploying familiar, open-source, system-level compilation toolchains for quantum-classical computing today.

Community Efforts on Quantum Compilers

Any compilation toolchain starts with the definition of a robust intermediate representation (IR) that languages can lower to and that can be further lowered to native code for a wide array of compute backends. There have been a number of recent community-wide efforts focused on the design and implementation of quantum IRs for future compiler technologies. One effort that is important to highlight is the Practical Intermediate Representation for Quantum Computing (PIRQ) working group within the broader Quantum Economic Development Consortium (QED-C). The PIRQ effort has brought together researchers from across industry, academia, and the national laboratories to discuss the concrete requirements and recommendations for any future robust, extensible, and unified intermediate representation for quantum computing. The working group hosted a multi-day workshop in July of this year bringing together interested parties from across the quantum computing landscape to demonstrate currently available approaches and distill and discuss common features and requirements. The usual feature requirements were discussed — things like mapping available language approaches to any desired quantum backend. More subtle features also came to the forefront throughout participant demonstrations and discussions - the need for an adaptable and fungible IR that could describe multiple layers of quantum language abstraction, and the need to ensure integration with existing classical compiler infrastructures, like the LLVM. These unique features were actually demonstrated by a number of independent institutional approaches, thereby highlighting their unique and innate value.

Concurrently, on the topic of LLVM for quantum computing, another community effort has arisen that seeks to bring together researchers across industry, government, and academia to define a concrete specification for a quantum-classical runtime API at the LLVM IR level of abstraction. The QIR Alliance (here, QIR stands for Quantum Intermediate Representation) is a new open source community within the Linux Foundation that seeks to develop forward-looking quantum-classical intermediate representations in order to enable full interoperability within the quantum software ecosystem. This organization has a special focus on enabling a QIR at the LLVM IR level, as well as supported tooling around this unified representation. Currently, the organization hosts an LLVM based specification for quantum computing (more on this in the next section), tools and python bindings for generation, optimization, and transformation of this IR representation, and the QCOR C++ compiler, which has put forward compiler tools that lower OpenQASM 3 to the QIR. This organization and the work that it has proposed has garnered broad support from the community, and as of this writing, Microsoft, Oak Ridge National Laboratory, Quantinuum, Rigetti, Quantum Circuits Inc., and NVIDIA are all involved and contributing.

LLVM-based Quantum Intermediate Representations

Let’s first focus on work being done to enable quantum integration within the LLVM. As noted above, a specification has recently been proposed that enables integration of common low-level quantum computing intrinsic operations (quantum register allocation deallocation, qubit addressing, instruction/gate invocation, etc.) at the LLVM IR level. The Quantum Intermediate Representation (QIR), put forward by researchers at Microsoft in collaboration with partners from industry and the national laboratories, represents a concrete API specification defined at the LLVM IR level for common quantum computing tasks. The QIR specifies the declaration and signature of external runtime library functions that perform low-level quantum operations. Moreover, it defines opaque types for qubits, measurement results, and general arrays, thereby allowing runtime library implementations of the QIR to concretely specify the internal structure of these types.

To make this all a bit more concrete, here’s an example for the creation of a simple two-qubit Bell state:

The specification declares functions for common operations related to quantum-classical computing. The above example demonstrates how we have functions for allocating qubits as an opaque array of opaque qubit types, as well as functions for addressing those qubit instances and performing quantum and classical operations on them. All that is required is that an appropriate implementation of this library API is specified at link time. Implementers are free to provide these functions in a way that best fits their needs. Therein lies the extensibility of this approach — QIR is a unified representation that can enable execution on any platform via an appropriate link-time specification of a QIR runtime library implementation. Moreover, its power and utility derives from its natural extension of the LLVM IR. It retains the entire LLVM software toolchain and ecosystem — many languages lower to the LLVM, linking QIR implementations is readily available at the command line, and transformations on the QIR LLVM instances can be done through routine LLVM passes and its corresponding pass management system. The QIR does not natively extend the list of provided LLVM IR Instructions (a notoriously difficult task requiring a complete fork, and future maintenance, of the system), but instead expresses quantum functionality as a declared, yet not implemented, runtime library API. With the QIR, the broader quantum computing community has started to define a common, unified compiler representation for quantum programs that high-level languages can target, can be optimized and generally transformed via routine pass implementations, and can ultimately be lowered to executable code targeting vendor-provided quantum computers.

Of course, the Bell state is not a super illuminating example demonstrating the true utility of embedding a quantum-classical IR within the LLVM. The true utility of the LLVM is found in its wealth of existing classical control flow utilities and IR passes that analyze and simplify the code to make it more efficient. Check out the example below where we have a 15 qubit GHZ state coded up in OpenQASM 3, leveraging typical classical control flow: Notice we have the same QIR specification operations on opaque qubit and array types, but that the loop has been succinctly expressed using standard classical LLVM instructions, specifically the phi node and branch statements. This is what we mean when we say don’t reinvent the wheel for the classical side of quantum-classical compilation. There is a wealth of existing compiler IR technologies that are open and can be leveraged in the definition of a hybrid IR for quantum computing. Moreover, by building upon LLVM, we pick up classical optimization passes for free. For example, in the above loop, we know that there are a constant number of iterations (14). The LLVM IR Pass system has various implementations that can detect something like this and unroll the loop. By turning these passes on with -O3, we see the following simplified QIR code:

This type of optimization is nice in the NISQ era, the above code could be easily transpiled to the native gate set and assembly input for any of the publicly available quantum computing architectures.

Multi-Level Quantum IR

The second feature highlighted from broader community discussions is the notion of requiring multiple levels of IR abstraction for the typical quantum-classical computing compilation pipeline. The QIR represents just one level of abstraction in the compiler lowering pipeline, and it is really the lowest machine level before necessary transformation to analog pulses for physical control of the quantum computer. There are, of course, other layers of abstraction, specifically those that may sit closer to the programmer and the language being used. Oftentimes, compiler optimizations may be better suited for language-levels of abstraction, where more of the original intent and semantics are still expressed. Moreover, multiple levels of IR abstraction can provide a mechanism for efficiently mapping languages to object code via the LLVM-based QIR. In other words, can we provide a robust and pre-implemented infrastructure that makes it simple to lower languages through multiple levels of IR abstraction to something at the quantum-classical machine level like the QIR?

Recent work has begun to tackle these challenges via a novel classical compiler IR framework called the Multi-Level Intermediate Representation (MLIR). The MLIR promotes a flexible approach to defining compiler IRs as well as a system for progressive lowering of one IR abstraction layer to lower ones. With this approach, you can define a language-level IR incorporating the unique semantics of the programming language, perform language-specific optimizations, and then take that representation down to lower level IR abstractions like the LLVM machine-level IR. If you can lower down to the LLVM IR, then you can readily generate executables and object code with the existing LLVM toolchain.

Figure 1: Demonstration of MLIR layers and lowering languages to a QIR representation.

The MLIR has been recently extended to support quantum computing language features via a new dialect implementation contributed to the QCOR C++ compiler from ORNL (in the MLIR, a dialect is a collection of language-IR-specific operations). This dialect defines operations that are close to typical features present in available quantum languages, and most importantly, defines the translation mechanism necessary for translating that MLIR dialect representation down to the LLVM IR in a manner that is adherent to the QIR specification. Moreover, since dialects in the MLIR are modular components, we are free to leverage existing dialects for classical control flow, variable declarations and allocations, and function declaration and implementation. One truly gets a hybrid quantum-classical IR with the ability to optimize and lower to a QIR representation. In this way, as seen in Figure 1, prototyping new quantum-classical language compilers amounts to mapping language parse or abstract syntax trees to the quantum-classical MLIR representation, and then leveraging the existing infrastructure to lower down to executables and object code.

Let’s demonstrate this workflow with the GHZ code again, but this time with a bit of added complexity — specifically, we’ll pull out the controlled-not operation into its own subroutine and add classical variable declarations. Moreover, we’ll add in some X gates that should all effectively cancel out, and that any good compiler should be able to detect and throw away. In order to lower a language like OpenQASM 3 (or any other quantum language) to the QIR, one simply has to map the language parse or abstract syntax tree to an MLIR representation leveraging the newly developed Quantum Dialect in tandem with pre-implemented classical dialect operations. This MLIR Quantum Dialect, as well as the rest of the infrastructure that performs quantum-classical optimizations and progressively lowers down to the LLVM, is provided by the open-source QCOR project. You’ll notice in the MLIR representation that one can define classical variables and leverage typical control flow structures like loops and conditionals, and that stand-alone functions can also be declared and defined. The great thing about this representation is that the language level semantics are retained, and quantum and classical optimizations can be applied. Specifically, not that all quantum operations consume a quantum.Qubit value, and produce a new quantum.Qubit value. This feature allows one to effectively map out value use-define chains that provide key insight into how quantum data flows through the IR nodes. This data flow enables one to pick out common patterns efficiently, specifically those patterns that are common circuit optimizations. For example, the extra X operations introduced present a use-define pattern whereby an X gate consumes a qubit and produces another qubit value, which is then consumed by another X gate operation. This pattern can be easily searched for by the compiler and the operations can be thrown away. Moreover, by applying common classical optimization passes first, like function inlining, we can optimize these quantum gates away across loop boundaries.

Employing available classical optimizations and using pattern recognition on qubit data flow to pick out quantum circuit optimizations, we arrive at the above code snippet ghz_opt. Notice that the loop has been unrolled, functions inlined, and all unnecessary quantum operations have been removed.

After lowering this MLIR instances down to the LLVM IR adherrent to the QIR, one can readily generate executable object code. All that is left to do is link to any library that implements the QIR specification. The QCOR project provides one that delegates to the XACC framework, thereby enabling this simple GHZ code to run on IBM, Rigetti, IonQ, and Honeywell physical architectures, as well as a wide-array of simulators. As seen in the above shell commands, one simply specifies the backend to target (cuQuantum SDK, IBM physical backend, etc.) and the above lowering workflow takes the OpenQASM 3 code down to a hybrid quantum-classical binary executable.


These are early days to be sure, but we are seeing improvements in quantum hardware implementations with regards to things like lower noise, processing longer depth circuits, and tighter CPU-QPU integration and fast feedback and control. It is time to begin thinking about compiler architectures that enable performant interplay between quantum and classical resources. It is equally important to understand how quantum compilation strategies fit into the broader classical compilation pipelines in use today. Quantum computers are likely to work in tandem with classical computing resources, and it is important to design IR and software infrastructures that are ultimately integrable with classical workflows. Here we have provided a high-level view of recent work enabling such a performant compiler toolchain, and specifically how the community is beginning to leverage classical frameworks like LLVM and MLIR for future quantum-classical compiler integration. There is much to be done and these approaches are innately designed to be extensible, fungible, and modular, so that as quantum computers advance, so too can our compiler software ecosystems.

Get Started with the Concepts in this Blog

If anyone would like to quickly get up and running with these next-generation system-level quantum compiler technologies, we’ve put together a Docker image with the examples described in this blog post. To try it out, run the following

docker run -it qcor/cli-unitary-blog bash

Within the container, lower to MLIR and QIR, and build quantum-classical executables:

If you’d like to connect with Alex and learn more about the work in this blog, check out his LinkedIn and GitHub profiles!

This website is hosted on github, and our community follows this code of conduct.

If you have suggestions for changes then please open up a pull request!

©2020 Unitary Fund