-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restrict Split2QUnitaries
to run on UnitaryGate
s only
#13095
Conversation
One or more of the following people are relevant to this code:
|
Pull Request Test Coverage Report for Build 10723089932Details
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I'll make sure to update #13025 to reflect this change too.
This could arguably be considered a behavior change but I think we're in the grey area because the pass was always named Split2QUnitaries
(I totally missed the capital Q
which is lowercase for everything else) and the intent was always for this to be run after consolidate blocks. Also since this is actively breaking use cases that worked in < 1.2 I would treat this as the lesser change.
(cherry picked from commit 9898979)
Some of the logic inside the Split2QUnitaries pass was updated in a recently merged PR. This commit makes those changes so the rust implementation matches the current state of the previous python version.
* Fully port Split2QUnitaries to rust This commit builds off of #13013 and the other data model in Rust infrastructure and migrates the InverseCancellation pass to operate fully in Rust. The full path of the transpiler pass now never leaves Rust until it has finished modifying the DAGCircuit. There is still some python interaction necessary to handle parts of the data model that are still in Python, mainly for creating `UnitaryGate` instances and `ParameterExpression` for global phase. But otherwise the entirety of the pass operates in rust now. This is just a first pass at the migration here, it moves the pass to use loops in rust. The next steps here are to look at operating the pass in parallel. There is no data dependency between the optimizations being done for different gates so we should be able to increase the throughput of the pass by leveraging multithreading to handle each gate in parallel. This commit does not attempt this though, because of the Python dependency and also the data structures around gates and the dag aren't really setup for multithreading yet and there likely will need to be some work to support that. Part of #12208 * Update pass logic with changes from #13095 Some of the logic inside the Split2QUnitaries pass was updated in a recently merged PR. This commit makes those changes so the rust implementation matches the current state of the previous python version. * Use op_nodes() instead of topological_op_nodes() * Use Fn trait instead of FnMut for callback We don't need the callback to be mutable currently so relax the trait to just be `Fn` instead of `FnMut`. If we have a need for a mutable environment callback in the future we can change this easily enough without any issues. * Avoid extra edge operations in replace_on_incoming_qubits * Rename function
Summary
Fixes the remaining problems with #12970.
Details and comments
If we run
Split2QUnitaries
with an incomplete 1-q basis gate set, we can end up in the situation where a supported gate is split into 2UnitaryGate
objects that might not be representable in the current basis gate set. For exampleThis PR fixes the behavior by only running on
UnitaryGate
objects -- hence not changing the gate types existing in the circuit.