So far, this PR adds a pass that can merge the following gates:

• gphase
• rx, ry, rz
• rxx, ryy, rzz, rzx

I'm not sure about how to merge the remaining gates mentioned in #898. I have the feeling that they are fundamentally different and cannot be merged as easily because the respective gates cannot be decomposed into something that commutes.

I also still have to figure out why the tests are failing on Windows.

I already texted you privately, but if you have any input, I would be very interested, @burgholzer, @DRovara, and @ystade. :)

I'm not sure about how to merge the remaining gates mentioned in #898. I have the feeling that they are fundamentally different and cannot be merged as easily because the respective gates cannot be decomposed into something that commutes.

I did some more thinking on this topic and I might have an idea: Rotations by Euler Angles are known to be difficult to compose from multiple rotations. That's why quaternions (https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation) are often used by game engines to represent rotations.

I think we might be able to do the same thing here: first translate the three Euler angles to quaternions, then we combine the multiple rotations into one single rotation and then we translate back into Euler angles. If you want we can also chat about this in person tomorrow, @denialhaag.

I'm not sure about how to merge the remaining gates mentioned in #898. I have the feeling that they are fundamentally different and cannot be merged as easily because the respective gates cannot be decomposed into something that commutes.

I did some more thinking on this topic and I might have an idea: Rotations by Euler Angles are known to be difficult to compose from multiple rotations. That's why quaternions (https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation) are often used by game engines to represent rotations.

I think we might be able to do the same thing here: first translate the three Euler angles to quaternions, then we combine the multiple rotations into one single rotation and then we translate back into Euler angles. If you want we can also chat about this in person tomorrow, @denialhaag.

Have a look at the current Qiskit code in that regard. I remember that they are doing something very similar in the code since recently. Might serve as some good inspiration.

The rules for u gates should be fairly straight forward, I believe. u2 is only a special case of u so that should work similarly.

The two qubit gates are a bit more special.
I think that two of these with the same beta value just add up the angles of the first parameter. I am not aware of any more general rules for that at the moment.

In general, merging might not be particularly easy here. But cancellation is fairly easy to decide as also indicated by the code linked in the issue description. Maybe those gates should be included as special rules there.

Just my two cents here though.

I did some more thinking on this topic and I might have an idea: Rotations by Euler Angles are known to be difficult to compose from multiple rotations. That's why quaternions (https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation) are often used by game engines to represent rotations.

I think we might be able to do the same thing here: first translate the three Euler angles to quaternions, then we combine the multiple rotations into one single rotation and then we translate back into Euler angles. If you want we can also chat about this in person tomorrow, @denialhaag.

@DRovara, yes, an in-person chat would be nice! I'll be in the office in a bit! :)

Have a look at the current Qiskit code in that regard. I remember that they are doing something very similar in the code since recently. Might serve as some good inspiration.

The rules for u gates should be fairly straight forward, I believe. u2 is only a special case of u so that should work similarly.

The two qubit gates are a bit more special. I think that two of these with the same beta value just add up the angles of the first parameter. I am not aware of any more general rules for that at the moment.

In general, merging might not be particularly easy here. But cancellation is fairly easy to decide as also indicated by the code linked in the issue description. Maybe those gates should be included as special rules there.

Just my two cents here though.

@burgholzer, thanks for the ideas! I'll have a look at the Qiskit implementation!

For reference, the Qiskit pass is implemented here.

For reference, the Qiskit pass is implemented here.

I created #1029. 👍

After an offline discussion with @DRovara, I removed the feature of erasing gates whose parameters meet the necessary conditions. This should only be supported for gates with static parameters. To this end, I created #1030.

After an offline discussion with @DRovara, I removed the feature of erasing gates whose parameters meet the necessary conditions. This should only be supported for gates with static parameters. To this end, I created #1030.

Just for context, the idea was

rx(a), rx(b) ==> rx(a + b), then if a + b === 0, the gate can be removed.

However, since this PR works with dynamic operands, we can't really know if a + b === 0.
The previous solution was to check if a and b were arith.constant expressions and getting their numeric values from there, but in my opinion, it makes sense to have this idea covered by a different constant folding path that converts the arguments from dynamic operands to static attributes.

Once we have that, a + b === 0 can be checked in the merge process for rotation gates that use static attributes (see #1030).