Add first optimization passes to MQTOpt

[DRovara]

Description

This pull request adds the first optimization passes to MQTOpt.

All new passes can be called using the quantum-opt tool.

--cancel-consecutive-self-inverse

This pass finds consecutive applications of self-inverse gates and cancels them.

Original:

%q_1 = mqtopt.x() %q_0 : !mqtopt.Qubit
%q_2 = mqtopt.z() %q_1 : !mqtopt.Qubit
%q_3 = mqtopt.z() %q_2 : !mqtopt.Qubit

After pass:

%q_1 = mqtopt.x() %q_0 : !mqtopt.Qubit

--quantum-sink

This pass sinks (single-qubit*) quantum gates into deeper branches.

Original:

%q_1 = mqtopt.x() %q_0 : !mqtopt.Qubit
cf.cond_br %i, ^then(%q_1 : !mqtopt.Qubit), ^else(%q_1 : !mqtopt.Qubit)

^then(%q_1then : !mqtopt.Qubit):
  cf.br ^continue(%q_1then : !mqtopt.Qubit)

^else(%q_1else : !mqtopt.Qubit):
  %q_2 = mqtopt.x() % q_1else : !mqtopt.Qubit
  cf.br ^continue(%q_2 : !mqtopt.Qubit)

^continue(%q_3 : !mqtopt.Qubit):
  ...

After pass:

cf.cond_br %i, ^then(%q_0 : !mqtopt.Qubit), ^else(%q_0 : !mqtopt.Qubit)

^then(%q_0then : !mqtopt.Qubit):
  %q_1then = mqtopt.x() %q_0then : !mqtopt.Qubit
  cf.br ^continue(%q_1then : !mqtopt.Qubit)

^else(%q_0else : !mqtopt.Qubit):
  %q_1else = mqtopt.x() %q_0else : !mqtopt.Qubit
  %q_2 = mqtopt.x() %q_1else : !mqtopt.Qubit
  cf.br ^continue(%q_2 : !mqtopt.Qubit)

^continue(%q_3 : !mqtopt.Qubit):
  ...

Note that, due to linear types and SSA, branch "calls" and "returns" will always need to pass the variables needed by a block.

*currently, this pass only works for single-qubit gates. Multi-qubit gates might have multiple users and therefore, the logic has to be adapted for them.

Checklist:

• The pull request only contains commits that are related to it.
• I have added appropriate tests and documentation.
• I have made sure that all CI jobs on GitHub pass.
• The pull request introduces no new warnings and follows the project's style guidelines.

[burgholzer]

Hey @DRovara 👋🏼

Many thanks for this PR. This is looking great!
Most of the comments are just minor things to fix up.
2 or 3 are more so on how we want to handle certain things and how we want to expand them in the future.

One last thing: I still believe that there also might be value in doing the reverse of the QuantumSink pass you created. Pulling out common operations at the beginning or the end of branches reduces the code within the branches themselves.
For IfElse statements that might not be that important, but for loop constructs like for or while, this could save significant resources. I believe this typically goes under the name of "hoisting" (see, e.g., https://compileroptimizations.com/category/hoisting.htm)
Could also be a nice follow-up.

[burgholzer]

It would be fairly easy to extend this to not only work on self-inverse gates, but to really cancel gates that are the inverse of another.
Easy examples include:

• T, Tdg
• S, Sdg
• Sx, Sxdg

The CircuitOptimizer supports some of these already in the singleQubitGateFusionPass https://github.com/cda-tum/mqt-core/blob/d71fa7c1ba73af053327c6b9900529c0ffb7e176/src/circuit_optimizer/CircuitOptimizer.cpp#L178-L271

Naturally, it would also be kind of straight forward to extend this to rotation gates.
We have rules for how to generate the inverses of all supported MQT gates within the DD package: https://github.com/cda-tum/mqt-core/blob/d71fa7c1ba73af053327c6b9900529c0ffb7e176/src/dd/Operations.cpp#L75-L134

I am fine with merging the pass as it is for now. But I believe we should be quickly expanding it for further use cases. Maybe worth to turn some of the above into a proper issue description.

[DRovara]

I have adapted the pass to now also cancel the other inverse gates like S and Sdg.

However, I feel like merging rotation gates would make more sense as its own Pass (or at least its own Pattern) to keep these patterns as atomic as possible.

[DRovara]

Here is the issue that proposes that feature #898

[burgholzer]

Side note: at least from a reviewer perspective it seems laborious to construct these tests compared to how similar tests are written for the CircuitOptimizer (https://github.com/cda-tum/mqt-core/blob/main/test/circuit_optimizer/test_single_qubit_gate_fusion.cpp).
Is this a concern? Typically, we should strive to write many tests for the respective functionality to ensure this is working. DO we have a strategy for making that easier or is the current setup just fine?

[DRovara]

Absolutely agreed. Writing these tests is a pain. I spent more time fixing typos in the expected test results than I spent fixing bugs that were uncovered by these tests. Also, they end up only testing the string representation of the output which is obviously also limited.

Long-term I think we should search for a more efficient way to do this.
LIT tests allow you to run any verification program like

// RUN: quantum-opt %s --mqt-core-round-trip | <your-program> %s

So maybe we can find something that works better than FileCheck or we write our own program for that.
Of course, that would still be just a test of the string output.

Alternatively, I believe there is nothing that stops us from using these gtests also on the MLIR data structures.

In any case, I think this is a issue for the future, not for this PR

[burgholzer]

In any case, I think this is a issue for the future, not for this PR

Most definitely. Maybe something worth opening an issue on.

Alternatively, I believe there is nothing that stops us from using these gtests also on the MLIR data structures.

When I read through the Catalyst source code, I saw that MLIR/LLVM apparently has some integration with googletest already (https://github.com/PennyLaneAI/catalyst/blob/9f1c8f0b84906c2f8e65c899f5f305f449064585/mlir/CMakeLists.txt#L100-L145). Might be worth exploring that in the near future.

[DRovara]

#899 now summarizes the current testing situation/possible solutions.

[burgholzer]

As far as I remember, there is a way to combine multiple tests into one file with MLIR.
I believe it might make sense to create one test file per optimization pass and have several (small) test cases in each of them.

[DRovara]

Good idea. Apparently there are multiple ways to achieve that, butmaybe the best (from my limited research) seems to be using the split-input-file method. This splits the test file into slices based on // ----- markers. Each of these markers can then have a description that says what the test does etc.

Advantages:

• Simple and straightforward to extend
• Clean
  Disadvantage:
• When a test fails, it will always only tell us the name of the failed test file. Using the -v option also gives us the location in the code where the test failed, but we will never get a definitive output that says "slice X failed".

An alternative would be using CHECK-PREFIXES. This involves adding a label to every CHECK instruction based on the corresponding test case. This way, we could have more information about what test failed exactly, but the maintenance overhead is a lot higher this way.

The LLVM testing guidelines suggest using these prefixes for e.g. testing different platforms, not to identify different test cases. ChatGPT even says using prefixes to differentiate test cases is bad practice.