Lukas Burgholzer

> @burgholzer @ystade, I'm running into QDMI issues that I hope you can advise on. I added support for `QDMI_Job` to the FoMaC library ([here](https://github.com/munich-quantum-toolkit/core/blob/fa196a93f441fbee7e944bae4051c0dc6a79dd79/include/mqt-core/fomac/FoMaC.hpp#L202-L227)) and Python bindings ([here](https://github.com/munich-quantum-toolkit/core/blob/fa196a93f441fbee7e944bae4051c0dc6a79dd79/bindings/fomac/fomac.cpp#L29-L63) and...

At the moment, this PR is purely additive to the existing infrastructure. It introduces: - the Quartz dialect (=MQTRef) - the Flux dialect (=MQTOpt) For both of these dialects, the...

> Why is there a `quartz.yield` operation, is it needed? It's not in the RFC draft (as opposed to `flux.yield`) Every block needs a terminator, even though there might not...

> I'm adding a quick update on this just for a better overview. > > At the moment, we convert almost all the gates supported by our dialect `MQTOpt` to...

Yeah. Let's do that then for now. Decompositions for all of these can easily be derived from Qiskit. I believe we even have some decompositions within the MQT Core DD...

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...

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...

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...

The above description actually has two components: - We currently need to pin to the exact LLVM commit catalyst is using to make the plugin work - As a consequence...

Created #1124 for tracking the second issue.