⚛️ quantum physics

Integrating Quantum Software Tools with(in) MLIR

This paper provides a practical guide for quantum software engineers to overcome the steep learning curve of MLIR by demonstrating a concrete integration of Xanadu's PennyLane and the Munich Quantum Toolkit, thereby fostering interoperability and modularity in the quantum software ecosystem.

Original authors: Patrick Hopf, Erick Ochoa Lopez, Yannick Stade, Damian Rovara, Nils Quetschlich, Ioan Albert Florea, Josh Izaac, Robert Wille, Lukas Burgholzer

Published 2026-01-29

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Patrick Hopf, Erick Ochoa Lopez, Yannick Stade, Damian Rovara, Nils Quetschlich, Ioan Albert Florea, Josh Izaac, Robert Wille, Lukas Burgholzer

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Problem: A Tower of Babel in Quantum Computing

Imagine the world of quantum computing as a bustling international city. On one side, you have software developers (like the team behind PennyLane) who write programs in their own unique language. On the other side, you have hardware engineers (like the team behind MQT) who build the machines and tools to run those programs, speaking a completely different language.

Right now, if a developer wants to use a specific tool from the hardware team, they can't just hand over their code. They have to translate it into a "universal language" (like OpenQASM), which is like translating a novel into a basic, broken version of English just so a machine can read it. Then, the hardware team has to translate that broken English back into their own language to do the work.

The paper calls this a "workaround." It's slow, it loses important details (like which specific part of the machine a piece of code is talking to), and it requires a lot of extra software just to act as a translator. It's like trying to send a complex blueprint to a construction crew by first drawing it on a napkin, taking a photo of the napkin, and then having the crew redraw it from the photo.

The Solution: MLIR (The Universal Translator)

The paper introduces MLIR (Multi-Level Intermediate Representation). Think of MLIR not as a single language, but as a universal translator booth or a master blueprint system that everyone agrees to use.

In the world of classical computers (like your laptop), this system already exists and works great. It allows different software tools to talk to each other seamlessly without losing information. The authors argue that quantum computing needs this same system to stop reinventing the wheel every time a new tool is built.

The Challenge: The "Steep Cliff"

The problem is that MLIR is incredibly complex. It's like trying to learn how to build a skyscraper when you've only ever built sandcastles.

The Barrier: Most quantum software engineers come from physics or math backgrounds and speak "Python." MLIR is built on "C++" and uses very abstract, heavy-duty engineering concepts.
The Result: Many people want to use this universal translator, but the learning curve is so steep that they give up, leaving the "Tower of Babel" problem unsolved.

What This Paper Does: A "How-To" Guide

This paper is essentially a practical field guide for quantum engineers who are afraid of that steep cliff. The authors (a mix of researchers from Munich and Xanadu) decided to try connecting two major tools: PennyLane (a popular programming framework) and MQT (a toolkit for optimizing circuits).

Instead of just saying "MLIR is great," they showed exactly how to do it.

The Analogy: The Plugin System

Imagine you have a high-end camera (PennyLane). You want to add a new lens (MQT's optimization tool).

The Old Way: You have to take the camera apart, solder the lens directly onto the sensor, and hope it fits. If you want to change the lens later, you have to break the camera again.
The Paper's Way: They built a universal mount (a plugin). They showed how to create a small, modular piece of software that snaps onto the camera. This piece knows how to talk to the lens. Now, you can swap lenses in and out instantly without breaking the camera.

The Key Steps They Took

Created a "Dialect" (A Custom Vocabulary): They built a specific set of rules within MLIR that speaks the language of the MQT toolkit. This is like creating a specialized dictionary that translates MQT's specific instructions into the universal MLIR language.
Built the "Plugin": They packaged this dictionary and the translation rules into a small, downloadable file. This means other people don't have to rebuild the entire MLIR system; they just download the plugin and it works.
Demonstrated the Magic: They showed that a program written in PennyLane could be sent directly to the MQT optimizer and back, all inside the MLIR system.
- Before: Write code $\rightarrow$ Translate to text $\rightarrow$ Read text $\rightarrow$ Translate to code $\rightarrow$ Optimize $\rightarrow$ Translate back. (Slow, messy, error-prone).
- After: Write code $\rightarrow$ Send to MLIR $\rightarrow$ Optimize $\rightarrow$ Send back. (Fast, clean, no information lost).

Why This Matters (According to the Paper)

No More "Lost in Translation": Because the code stays inside the MLIR system, no details are lost during the swap. The system knows exactly which "qubit" (quantum bit) is where.
Modularity: Developers can now build small, specialized tools (plugins) that work together. They don't need to be experts in the entire MLIR system to use it; they just need to build their specific plugin.
Open Source: The authors didn't keep this secret. They put all their code online so other engineers can copy their "plugin" and start building their own connections.

Summary

This paper is a hand-holding tutorial for quantum software engineers. It says: "We know MLIR is scary and complicated, but we figured out a way to use it to connect two major quantum tools without getting overwhelmed. Here is the blueprint, the tools, and the step-by-step instructions so you can do the same thing with your own tools."

By doing this, they are helping to build a future where quantum software tools can plug and play together, rather than struggling to translate between isolated islands.

Technical Summary: Integrating Quantum Software Tools with(in) MLIR

Problem Statement

The quantum software ecosystem is currently characterized by a lack of interoperability. While classical compilation has matured around shared frameworks like LLVM and its Multi-Level Intermediate Representation (MLIR), quantum compilation remains fragmented. Most quantum software tools are developed independently, often by experimentalists rather than compiler engineers, resulting in ad-hoc solutions and isolated data structures.

This fragmentation forces developers to rely on cumbersome workarounds to integrate different tools. For instance, moving a program from one framework (e.g., Xanadu's PennyLane) to another (e.g., the Munich Quantum Toolkit's QMAP) often requires exporting to a text-based format like OpenQASM, parsing it, and re-importing it into the target tool's internal Intermediate Representation (IR). This process introduces significant runtime overhead, risks losing structural and semantic information (such as qubit mappings), and necessitates complex dependency chains (e.g., requiring Qiskit solely for OpenQASM parsing).

Although MLIR offers a robust solution for unifying compilation flows through custom dialects and pass pipelines, its adoption in the quantum domain is hindered by a steep learning curve. Quantum software engineers, typically proficient in Python, face barriers related to MLIR's C++ implementation, complex template patterns, and the sheer scale of the LLVM infrastructure.

Methodology

The paper presents a practical, hands-on guide to overcoming these barriers by demonstrating the integration of two major quantum software frameworks: Xanadu's PennyLane (specifically its Catalyst just-in-time compiler) and the Munich Quantum Toolkit (MQT). The authors employ a modular plugin-based approach within the MLIR ecosystem to enable seamless interoperability without requiring users to compile the entire LLVM project.

The integration methodology consists of three primary technical components:

Dialect Definition (MQTOpt):
To bridge the gap between PennyLane's native MLIR Quantum dialect and MQT's internal C++ QuantumComputation IR, the authors developed a custom MLIR dialect named MQTOpt.
- Semantics: MQTOpt closely mirrors the semantics of the MQT Core IR but enforces Static Single Assignment (SSA) and a single-use constraint (linear typing). This constraint naturally enforces the quantum no-cloning theorem, ensuring each qubit is defined and used exactly once.
- Structure: Unlike the generic Catalyst Quantum dialect, which represents gates as generic operations with a gate_name attribute, MQTOpt defines specific operations for each gate (e.g., mqtopt.H, mqtopt.x). It also introduces specific types like QubitRegister and operations for qubit extraction and insertion, facilitating easier tracking of physical qubit assignments.
Transformation Patterns:
The authors implemented conversion patterns to translate between the Catalyst Quantum dialect and the MQTOpt dialect.
- These patterns utilize MLIR's TypeConverter and ConversionPatterns to handle the translation of operations and types while leaving non-quantum logic untouched.
- Crucially, these patterns enforce the single-use constraint required by MQTOpt, a non-trivial rewrite logic step.
Plugin Infrastructure:
To lower the entry barrier, the integration is packaged as a shared library plugin.
- The custom dialect and transformation passes are compiled into a dynamic library (.so/.dylib).
- This allows tools like PennyLane to load the plugin at runtime via the MLIR pass manager, enabling the execution of a full compilation pipeline (e.g., mapping a circuit) without the user needing to build the entire MLIR or Catalyst source code.
- The pipeline is orchestrated using the mlir-opt command-line utility, which loads the dialect and pass plugins to execute a "round trip" (Catalyst $\to$ MQTOpt $\to$ QMAP mapping $\to$ MQTOpt $\to$ Catalyst).

Key Contributions

Practical Integration Guide: The paper provides a concrete blueprint for quantum software engineers to integrate their tools into the MLIR ecosystem, moving beyond theoretical proposals to a working implementation.
MQTOpt Dialect: The introduction of a specialized MLIR dialect that aligns with existing quantum tool semantics (MQT Core) while adhering to MLIR's SSA and linear typing constraints.
Modular Plugin Architecture: A demonstration of how to encapsulate complex compiler logic (dialects and passes) into lightweight, distributable plugins, avoiding the need for monolithic builds of the LLVM project.
Open-Source Implementation: The full code for the dialect, passes, and plugin infrastructure is released as open source within the MQT repository, serving as a reference implementation for the community.

Results

The integration successfully enables a seamless workflow between PennyLane and MQT tools:

Elimination of Text-Based Intermediaries: The workflow no longer requires exporting to OpenQASM and re-parsing. The program flows directly through MLIR dialects, preserving structural information and eliminating parsing overhead.
Reduced Dependencies: The need for intermediate dependencies like Qiskit (used previously for OpenQASM handling) is removed.
Functional Mapping: The system successfully performs a full round-trip compilation: a GHZ state circuit defined in PennyLane is converted to MQTOpt, mapped to a specific hardware topology using MQT's QMAP tool (which inserts necessary SWAP gates), and converted back to the Catalyst dialect for execution.
Usability: Users can trigger complex compilation flows (including hardware mapping) via simple Python decorators in PennyLane, abstracting away the underlying MLIR complexity.

Significance and Claims

The paper claims that this work serves as a "practical and hands-on guide" to lower the entry barrier for quantum software engineers adopting MLIR. Its significance lies in:

Fostering Interoperability: By providing a unified backbone, it allows disparate quantum tools to communicate directly, moving the ecosystem away from isolated "zoo" tools toward a cohesive software stack.
Leveraging Classical Expertise: It demonstrates how quantum software can benefit from decades of classical compiler infrastructure (optimization passes, modularity, and plugin systems) without reinventing the wheel.
Scalability: The modular plugin approach allows for the easy addition of new tools and dialects (e.g., future integration with NVIDIA's CUDA-Q or QIR) with minimal additional effort, as only conversion passes between dialects are required.
Community Enablement: By releasing the code and best practices, the authors aim to empower the quantum community to build more modular, interoperable, and integrated software stacks, ultimately guiding the development of quantum software that can be seamlessly integrated into classical and High-Performance Computing (HPC) environments.

The authors remain modest, noting that while the integration is successful, the learning curve for MLIR remains steep for those without compiler design backgrounds. However, they argue that the provided best practices and modular architecture significantly mitigate these challenges, making the adoption of MLIR a viable and necessary step for the maturation of the quantum software ecosystem.