Introducing Quantum Intermediate Representation (QIR)

Alan Geller

What is QIR

QIR is a new Microsoft-developed intermediate representation for quantum programs. It is based on the popular open-source LLVM intermediate language. QIR specifies a set of rules for representing quantum constructs in LLVM. It does not require any extensions or modifications to LLVM.

QIR is intended to serve as a common interface between many languages and target quantum computation platforms. Thus, while it supports Q#, QIR is not specific to Q#: any programming language for gate-based quantum computing can be represented in QIR. Similarly, QIR is hardware-agnostic: it does not specify a quantum instruction or gate set, leaving that to the target computing environment.

As quantum computing capabilities mature, we expect most large-scale quantum applications will take full advantage of both classical and quantum computing resources working together. LLVM provides QIR with full capabilities for describing rich classical computation fully integrated with quantum computation. Using LLVM also facilitates integration with the many classical languages and tools which are already supported by the LLVM tool chain. It also promotes the development of common language- and backend-independent optimizations and code transformations, based on a well-known and robust open-source framework.

In the coming years, we expect there to be exciting advances in how classical and quantum computations can interact at the hardware level. With QIR we intend to provide a single representation that can be used for both today’s restricted capabilities and the more powerful systems of the future. This will allow the community to experiment with and develop optimizations and code transformations that work today and that will remain useful tomorrow.

What is an Intermediate Representation

A common pattern in compilers is to start by compiling the source language into an intermediate representation. This intermediate form is typically designed to allow many different source languages to be represented. While still in the intermediate representation, the code can be optimized and transformed. Finally, once the actual target execution platform is known, the intermediate representation can be compiled to actual executable code.

This approach allows many source languages to share a common set of optimizers and executable generators. It also makes it easy to compile a single source language for many different targets. The intermediate representation provides a common platform that can be shared across many sources and targets and allows a great deal of re-use in compiler machinery.

What Does QIR Look Like

Since QIR is based on LLVM, QIR looks like LLVM.

For example, here is some simple Q# code to generate a Bell pair:

// Assumes that qb1 and qb2 are already in the |0> state
operation BellPair(qb1 : Qubit, qb2 : Qubit) : Unit
    CNOT(qb1, qb2);

When compiled to QIR, this becomes:

define void @BellPair__body(%Qubit* %qb1, %Qubit* %qb2) {
  call void @__quantum__qis__h(%Qubit* %qb1)
  call void @__quantum__qis__cnot(%Qubit* %qb1, %Qubit* %qb2)
  ret void

In this snippet, a few QIR features are apparent:

  • Operations in Q# (or any other quantum programming language) are represented by LLVM functions.
  • LLVM functions whose names start with __quantum__qis__ are reserved to represent operations in the quantum instruction set being used.
  • Qubits are represented as pointers to a named opaque structure type, %Qubit.

While the QIR for this trivial sample is very simple, QIR inherits all of the capabilities of LLVM to express loops, conditionals, and other complex control flow. QIR also inherits LLVM’s ability to express arbitrary classical computation.

What Can I Do With QIR

One application enabled by QIR is to use the clang compiler to compile QIR into executable machine code for a classical target. This provides an easy path to building a simulator in C or C++ by implementing the quantum instruction set functions mentioned above.

Another application is to use the standard LLVM “pass” infrastructure to write quantum optimizers that operate on QIR. The source- and target-independent approach of QIR allows optimizations to be used with many different computation languages and computing platforms.

QIR has been shared with some partners already to get early feedback. For instance, Oak Ridge National Laboratory’s Quantum Computer Scientist and XACC Project Alex McCaskey says “ORNL is working closely with the Microsoft quantum compiler team to enable compilation of high-level Q# programs to the diverse set of OLCF quantum hardware platforms via integration with the XACC quantum programming framework.”

Where Do I Find Out More

Today we’ve rolled out two QIR-related components:

  • The draft QIR Specification is posted here.
  • In the main Q# compiler repository, we’ve posted a compiler extension that generates QIR from Q#. Directions for using this tool are here.

How Can I Get Involved

Comments and suggestions on the draft QIR specification are welcome. Please post them as issues in the QIR specification repository using the appropriate template.

If you build an LLVM pass or other tool that works with QIR, we’d love to hear about it! Please see the contribution guide to learn how to get involved.


Discussion is closed. Login to edit/delete existing comments.

  • Rolf Huisman 0

    Interesting development. Given the capabilities of the LVVM platform, is the intention that this will also replace the current custom compiler extensions interfaces of the QDK today ?

    • Bettina HeimMicrosoft employee 0

      The intent is certainly to facilitate leveraging all the tools and possibilities that LLVM offers. Longer term we expect to invest into extensibility at the QIR level as well, in particular with the idea to facilitate a collaborative development of tools and optimizations that are common among different languages and backends. However, this will not replace the current extensibility of the Q# compiler. The Q# compiler extensions allow to plug into the compilation process at a higher abstraction level compared to an extension mechanism at the QIR level. What stage to plug in is most convenient depends on what exactly one would want to achieve. We hence expect that over time we will provide extensibility mechanisms for various layers in our stack.

Feedback usabilla icon