✨ MLIR - Add more passes

[flowerthrower]

Problem Statement

In order to have a compiler of value, we need to have at least a handful of optimization passes available.

Proposed Solution

These passes should ideally be atomar and independent of other passes. @taminob already found a few options
https://github.com/Qiskit/qiskit/blob/main/qiskit/transpiler/passes/optimization
https://github.com/CQCL/tket/tree/main/tket/src/Transformations

The ones selected for implementation are listed below:

• placeholderPass

[burgholzer]

Hey @flowerthrower and @taminob 👋🏼

Just wanted to throw another resource into the mix:
🔗 MQT Core CircuitOptimizer
We already implement several optimization passes in MQT Core as part of the CircuitOptimizer module.

Additionally, we’ve started defining MLIR-based passes here:
🔗 MQTOpt MLIR Transforms

Qiskit and TKET both offer extensive lists of optimization passes, though not all are actively used in their current compiler pipelines. When selecting passes to implement, it’s worth focusing on those that are still maintained and relevant. For Qiskit, I’d recommend looking at the passes already ported to Rust:
🔗 Qiskit Rust Transpiler Passes

Here’s a non-exhaustive list of passes I believe could be valuable to implement (in no particular order):

• Elide permutations – available in both Qiskit and MQT Core.
• Basis translation – not yet in MQT, but present in Qiskit and partially in TKET.
• Gate cancellation – e.g., commutative gate cancellation, identity removal, inverse cancellation.
• Swap reconstruction – implemented in MQT Core; works well in tandem with permutation elision.
• Clifford optimization – available in TKET and potentially via QMAP techniques.
• 1-qubit gate decomposition optimization – implemented in Qiskit; MQT Core aggregates runs of 1q gates.
• Remove diagonal gates before measurement – implemented in both Qiskit and MQT Core.
• Gates-in-basis analysis – available in Qiskit as an analysis pass.

A routing pass is already planned as part of MQT Core Issue #1079.

It might also be worth exploring techniques from BQSKit:
🔗 BQSKit GitHub

Lastly, TKET2 could be another interesting source of inspiration:
🔗 TKET2 GitHub

This list is meant to spark ideas—not a roadmap or requirement. Happy to hear your thoughts on which passes we should prioritize!

[flowerthrower]

Thank you very much @burgholzer. This will give @taminob plenty of passes to choose from. I would suggest starting with sth. simple (pure quantum / no classical control flow) and increasing complexity from there. Basically, feel free to pick whatever pass seems most easy to implement for you, @taminob, to get a feeling for the code and test setup.

[burgholzer]

Just from past experience, the easiest passes to accommodate are the gate cancellation and gate merging passes.
Maybe a good first start would be to look into the MLIR passes we already implemented and check whether there are easy ways to add functionality to them or to adapt them for further use cases.

Just for awareness: #916 already contains some open discussion on how particular optimizations might be realized.
If I recall correctly, @DRovara has a student who is planning to work on canonicalization in general. So it might be worth coordinating.

[flowerthrower]

Referencing this comment for future considerations. A fully fledged (RL or classical) compiler wil need to be able to:

Perform any optimisations that come to mind without restrictions
Break down 3+ qubit gates into sequences of 1- and 2-qubit gates.
Perform any optimizations on the sequence of 1- and 2-qubit gates.
Perform any layout algorithm that assigns circuit qubits to device qubits (this is part of what @MatthiasReumann is currently working on)
Perform any routing algorithm that makes the circuit fit the topology (also what @MatthiasReumann is currently working on; layout and routing may be combined in a single stage)
Perform any optimisations that preserve the connectivity of the circuit
Perform gate set synthesis method (for decomposing from arbitrary 1- and 2-qubit gates to a dedicated native gate-set of the target device)
Perform any optimisations that preserve the connectivity and the target gate-set.

Note, this might be the long-term goal, but it doesn't have to be fully implemented in order to set up the compilation pipeline.

[burgholzer]

Based on previous discussions, I am adding some pointers to relevant passes here.
In general, I would expect the Rust code in Qiskit to be the best reference for the lessons the IBM team has learned over the years that are now manifested in the Rust rewrite.

general pointers

• unitary synthesis: https://github.com/Qiskit/qiskit/blob/stable/2.1/crates/transpiler/src/passes/unitary_synthesis.rs
• basis translation: https://github.com/Qiskit/qiskit/tree/stable/2.1/crates/transpiler/src/passes/basis_translator

single-qubit gate decomposition

• https://github.com/Qiskit/qiskit/blob/stable/2.1/crates/transpiler/src/passes/optimize_1q_gates_decomposition.rs

• https://github.com/Qiskit/qiskit/blob/stable/2.1/crates/synthesis/src/euler_one_qubit_decomposer.rs

• https://quantum.cloud.ibm.com/docs/en/api/qiskit/qiskit.synthesis.OneQubitEulerDecomposer

two-qubit gate decomposition

• https://github.com/Qiskit/qiskit/blob/stable/2.1/crates/synthesis/src/two_qubit_decompose.rs

• https://quantum.cloud.ibm.com/docs/en/api/qiskit/qiskit.synthesis.TwoQubitBasisDecomposer