Support control flow in CommutationAnalysis
and CommutativeCancellation
#9423
Closed
Labels
Milestone
What should we add?
Part of #9417.
These two passes likely come as a pair, but this issue can be split in two if the discovery phase finds that that is preferable.
Details
The commutation analysis and cancellation is the main addition to the optimisation loop at transpiler optimisation level 2. This currently doesn't support control-flow, mostly because the
CommutationAnalysis
pass doesn't have a way of passing the information about nested blocks through toCommutativeCancellation
in the property set. To solve this, we need to:CommutationAnalysis
recurse through control-flow blocks, generating this analysisCommutativeCancellation
be able to interpret the new information, and enter control-flow blocks to effect it.This shouldn't be too difficult, beyond finding a data format; commutation relations can't span control-flow blocks, so a fairly simple recursive structure and visitor should be fine. When designing the data format, we may want to consider related work on
DAGCircuit.collect_runs
, since the collection and exchange of information is largely the same. See #9425.It is possible that a control-flow block could commute blockwise with another, or with non-controlled operations. For the purposes of this initial support, we do not need to support recognising these cases, but it will be a goal in the future. Please note on closure of this issue whether this was achieved or not.
The text was updated successfully, but these errors were encountered: