✨ MLIR - Conversion from llvm dialect to standard dialects

[li-mingbao]

Problem Statement

Once #1091 is merged, there will be a conversion from QIR in the llvm dialect into the mqtref dialect. During this conversion however only quantum operations are converted and other standard operation such as llvm.constant and llvm.func are not converted. While there are built-in transformation passes from higher level standard dialects such as arith or func to llvm there no conversion passes in the other direction.

This is not an issue for the conversion itself, but this could cause some issues later on during the transformation passes as they would expect an operation from a standard dialect and not from the llvm dialect.

Proposed Solution

The best solution would be to create a new conversion pass that converts llvm operations to std dialects operations. Looking at the documentation of the llvm dialect, there are probably a bunch of operations that do not need to be converted but atleast the standard operations that are likely to appear in QIR code and are required for the transformation passes need to be converted.
These are for example llvm.constant, llvm.cond_br or llvm.func.

[burgholzer]

Hey @li-mingbao 👋🏼

Just wanted to share a few thoughts and get your perspective on them:

From my understanding of MLIR and LLVM, LLVM sits strictly below MLIR in the compilation hierarchy. Typically, we lower from MLIR to LLVM—specifically to the LLVM dialect within MLIR. This seems to be supported by the issue description, which highlights MLIR’s strong support for lowering from its standard dialects to LLVM IR.

In that context, QIR is generally positioned as a low-level exchange format—essentially the output of the compiler toolchain that gets sent to the quantum device for execution. So the direction MLIR → QIR makes perfect sense.

What I’m less convinced about is the reverse direction: converting from QIR (LLVM-based) back to MLIR. It feels somewhat artificial to "raise" the abstraction level, and I imagine reconstructing structured control flow from raw LLVM IR could be quite complex—possibly even infeasible in some cases.

The only scenarios I can think of where this reverse conversion might be useful are:

• Treating QIR as an input format (i.e., a frontend language) for our compiler infrastructure.
• Enabling interoperability with compiler passes that operate exclusively on QIR.

So my main question is: how feasible do you think this reverse conversion is, especially beyond simple, straight-line quantum programs?

[li-mingbao]

Hey @burgholzer,

The reversion conversion is mainly used to use QIR as input format and connect it to the mqt environment.
So something like the pipeline QIR - mqtref - mqtopt - transformation/optimization passes - mqtref - QIR could also be possible.

For the question on how feasible the reverse conversion is, it depends on which operations will be actually relevant for the transformation passes. If they are not used, they can actually be ignored in my opinion.
A few operations are rather trivial and have a 1:1 conversion into a standard dialect operations but I can see how this can quickly explode once more and more conversions are required and the conversions become non-trivial.

[burgholzer]

Yeah, I can also see the value in potentially accepting QIR programs as input to our compiler pipeline. I have a gut feeling that supporting QIR programs as input will likely be very challenging, especially for anything beyond fairly simple circuits.
For QIR Base Profile programs, this should be totally doable. That profile is so restricted that I am absolutely sure we can map every classical LLVM concept to an MLIR one.
Anything beyond that seems hard to support for me, given how many special cases we would probably need to introduce when it comes to classical control flow.

Would it be an idea to explicitly limit the conversion from QIR to MQTRef to Base Profile QIR for now and make any extension to that a deliberate choice?
This would still involve conversions of things like llvm.func or llcm.constant, but would exclude control flow statements entirely.
Once that is established, we could gradually expand the support for further concepts.
How does that sound?

[li-mingbao]

Yes, this sounds good.
The QIR-mqtref conversion in #1091 also only addresses the conversion of Base Profile QIR programs into the mqtref dialect for now.

[burgholzer]

Okay. In that case this issue really boils down to

• translating the essential LLVM constructs for Base Profile QIR programs
• documenting that restriction (we will set up proper documentation infrastructure for the MLIR project shortly)
• implementing some verification that the input program can be entirely consumed, i.e., only uses valid constructs that we know how to work with.