What's the problem this feature will solve?
It would be great to additionally offer circuits on the mapped level as QIR in addition to QASM. At that level, it should also be guaranteed that the respective circuit can be represented in QIR. The same might not be true for higher levels in MQT Bench.
One immediate advantage of adding this is the ability to test QIR-based frameworks and tools.
Describe the solution you'd like
The mqt-bench Python package as well as the CLI should be able to generate QIR code.
Possible tools for making this possible are
Given how we will be exporting to OpenQASM 3 soon anyway, we might opt to simply rely on the qBraid solution to further translate the QASM file to QIR. Although I am slightly afraid that this process might not be fully lossless, I believe it should be fine at the mapped level.
We could think about extending this to
- the native-gates level (should be more or less easily possible)
- the target-independent level (might be possible for some of the programs, but probably not all. For example, multi-controlled Toffoli gates)
What's the problem this feature will solve?
It would be great to additionally offer circuits on the mapped level as QIR in addition to QASM. At that level, it should also be guaranteed that the respective circuit can be represented in QIR. The same might not be true for higher levels in MQT Bench.
One immediate advantage of adding this is the ability to test QIR-based frameworks and tools.
Describe the solution you'd like
The mqt-bench Python package as well as the CLI should be able to generate QIR code.
Possible tools for making this possible are
Given how we will be exporting to OpenQASM 3 soon anyway, we might opt to simply rely on the qBraid solution to further translate the QASM file to QIR. Although I am slightly afraid that this process might not be fully lossless, I believe it should be fine at the mapped level.
We could think about extending this to