Problem Statement
We would like to set up a canonicalization pass that fixes the order of operands in MQTOpt/MQTDyn operations in cases where a specific operand order is not required. This makes subsequent optimization passes (e.g. #1019) easier.
Based on initial brainstorming, this affects three scenarios:
- symmetrical gates: gates like
rxx target two qubits, but the order of these does not matter. rxx a, b is equivalent to rxx b, a.
- control qubits: the order of control qubits can always be swapped.
x a ctrl b, c is equivalent to x a ctrl c, b. This also applies to negative controls, however for operations with positive AND negative controls, the order of our assembly format requires all positive controls first, then all negative controls, so they cannot be mixed.
- gates where control and target are interchangeable: Example
cz: z a ctrl b is equivalent to z b ctrl a. This situation is not as clear as the other two (in my opinion), as we may have different reasons why some qubit should be a control or a target.
This issue first requires the general canonicalization pipeline to be set up for this project (see #916)
Proposed Solution
We should add a canonicalization pass (not a transformation pass) that fixes the order of operands in those situations.
Ordering by qubit index (by tracking back to the related extract operation) might be one possible approach.
Probably alphabetic ordering does not work, because the output variables might have different names than the inputs, so in a second gate that uses these same outputs as inputs the order may now be different.
Alternatively, maybe MLIR also already provides some ordering criterion - this would be the easiest solution.
For symmetrical gates and for control qubits, this should definitely be implemented. For gates where control and target are interchangeable, maybe it also makes sense to implement it.
I believe this pass can be implemented as a fold (see #916), because no other operation unrelated to the one considered should be modified by it - unless changing the order of the inputs of the user operation also counts as modifying a different operation. This requires some more reading.
Problem Statement
We would like to set up a canonicalization pass that fixes the order of operands in
MQTOpt/MQTDynoperations in cases where a specific operand order is not required. This makes subsequent optimization passes (e.g. #1019) easier.Based on initial brainstorming, this affects three scenarios:
rxxtarget two qubits, but the order of these does not matter.rxx a, bis equivalent torxx b, a.x a ctrl b, cis equivalent tox a ctrl c, b. This also applies to negative controls, however for operations with positive AND negative controls, the order of our assembly format requires all positive controls first, then all negative controls, so they cannot be mixed.cz:z a ctrl bis equivalent toz b ctrl a. This situation is not as clear as the other two (in my opinion), as we may have different reasons why some qubit should be a control or a target.This issue first requires the general canonicalization pipeline to be set up for this project (see #916)
Proposed Solution
We should add a canonicalization pass (not a transformation pass) that fixes the order of operands in those situations.
Ordering by qubit index (by tracking back to the related
extractoperation) might be one possible approach.Probably alphabetic ordering does not work, because the output variables might have different names than the inputs, so in a second gate that uses these same outputs as inputs the order may now be different.
Alternatively, maybe MLIR also already provides some ordering criterion - this would be the easiest solution.
For symmetrical gates and for control qubits, this should definitely be implemented. For gates where control and target are interchangeable, maybe it also makes sense to implement it.
I believe this pass can be implemented as a fold (see #916), because no other operation unrelated to the one considered should be modified by it - unless changing the order of the inputs of the user operation also counts as modifying a different operation. This requires some more reading.