Add flexible-layer mapper (FlexlayerSwap) pass

[itoko]

Summary

• Add FlexlayerSwap pass
• Add undirected_neighbors() to CouplingMap

FlexlayerSwap pass implements the swap mapping heuristics proposed in [1].

Details and comments

The algorithm considers the dependency graph of a given circuit
with less dependencies by considering commutativity of consecutive gates,
and updates blocking gates in the dependency graph by changing qubit layout
(= adding SWAPs). The blocking gates are the leading unresolved gates for
a current layout, and they can be seen as a kind of flexible layer
in contrast to many other swap passes assumes fixed layers as their input.
That's why this pass is named FlexlayerSwap pass.

[1] T. Itoko, R. Raymond, T. Imamichi, A. Matsuo, and A. W. Cross.
Quantum circuit compilers using gate commutation rules.
In Proceedings of ASP-DAC, pp. 191--196. ACM, 2019.
See https://arxiv.org/abs/1907.02686 (extended version of [1]) for the details of the algorithm.

FlexlayerSwap pass has possibility to dramatically reduce CNOT counts in mapped circuits. For example, see CNOT counts below, obtained by running isometry.IsometryTranspileBench.track_cnot_counts_after_mapping_to_ibmq_16_melbourne in my local environment. They show that the replacement of StochasticSwap with FlexlayerSwap can improve the performance of level1 pass manager on CNOT counts.

[Before (current level1 pass manager)]
======================== ==== ===== ===== ======

--                       number of output qubits

------------------------ -----------------------

 number of input qubits   3     4     5     6   

======================== ==== ===== ===== ======

           0              7     26    86   192  

           1              25    76   206   473  

           2              57   177   428   951  

           3              80   383   931   1989 

======================== ==== ===== ===== ======

[After (replacing StochasticSwap with FlexlayerSwap)]
======================== ==== ===== ===== ======

--                       number of output qubits

------------------------ -----------------------

 number of input qubits   3     4     5     6   

======================== ==== ===== ===== ======

           0              7     23    62   147  

           1              22    67   158   353  

           2              48   141   344   779  

           3              80   302   717   1569 

======================== ==== ===== ===== ======

For example, 21% reduction in (3, 6) case.

[CLAassistant]

All committers have signed the CLA.

[1ucian0]

@itoko any update here?

[itoko]

@1ucian0 I'm waiting the responses to the issue #2044. I personally think swap pass should return physical circuit. To complete this PR, I need the final decision on which (physical or virtual) circuit swap pass return.

[itoko]

@1ucian0 I'm not sure qiskit/transpiler/passes/mapping/algorithm is the right place or not, but I think it's not so bad to be there since modules under /algorithm (we may have better name than algorithm) are intended to be used only in some passes.

[1ucian0]

Suggested change

	self.assertEqual(dep_graph.qargs(0), [(qr, 1), (qr, 0)])
	self.assertEqual(dep_graph.qargs(0), [qr[1], qr[0]])

We are not using tuples anymore to refer to qubits.

[1ucian0]

Suggested change

	# (C) Copyright IBM 2017.
	# (C) Copyright IBM 2019.

[1ucian0]

I think it would be nice to extract the dependency graph construction as an analysis pass. What do you think @ajavadia

[kdk]

I think it would be nice to extract the dependency graph construction as an analysis pass. What do you think @ajavadia

I agree this would be a good enhancement, but I think we can tackle this in a follow-up PR.

[1ucian0]

a swapper should work with "physical circuits" and no layout should be interpreted at this point. This is something that was decided after this PR was initially submitted... sorry about that :(

[1ucian0]

I think it could be better to have a standalone example, using a physical circuit (e.i written in terms of q qubits) and show how it works. Otherwise, after #3004 gets merged (it will soon), you can replace the swapper using the new API. The table from this PR might be handy to show the improvement. A link to the paper is could also be informative.

[ajavadia]

The dependency graph portion of this has been implemented in #3581 - so this PR needs to be updated. @itoko can you do that? Otherwise I think we should close this.

[itoko]

@ajavadia I can do that, but it might be better to reimplement our Flexlayer pass on the basis of the Sabre routing pass merged recently (#4537).
This is because the Flexlayer pass is very similar to the Sabre routing pass, accidentally we (@itoko and @skywalker2012 ) think of very alike routing algorithm independently at the same time ([1] and [2]).

The improvement in the Flexlayer pass from Sabre routing pass would be:

• Use of dependency graph
• Small change in the decay weight W so that it depends on the step size from the current layer (e.g. 0.5 for gates in the next layer, 0.25 for gates in the next next layer, etc)
• Use of bridge gates as well as swap gates (proposed in [3] = extended paper of [1])

I think I should close this PR and open a new PR that extends the Sabre routing pass (should I create a new subclass of Sabre routing pass?). What do you think? @ajavadia

I admit the Sabre layout pass, that implements Li's reverse traversal technique, is very cool and useful (That would be the main difference between [1] and [2] as I mentioned in [3]). I know I don't need to touch the layout pass.

[1] T. Itoko et al. Quantum circuit compilers using gate commutation rules. In Proceedings of the 24th Asia and South Pacific Design Automation Conference, pp. 191-196 (January, 2019).
[2] G. Li, Y. Ding, Y. Xie, Tackling the qubit mapping problem for nisq-era quantum devices, In Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems, ACM, April, 2019, pp. 1001-1014.
[3] T. Itoko et al. Optimization of quantum circuit mapping using gate transformation and commutation. Integration 70 (2020): 43-50.

[ajavadia]

Sure then you could probably just provide extra options to sabre

…

On Jun 25, 2020, at 3:10 AM, itoko ***@***.***> wrote:  @ajavadia I can do that, but it might be better to reimplement our Flexlayer pass on the basis of the Sabre routing pass merged recently (#4537). This is because the Flexlayer pass is very similar to the Sabre routing pass, accidentally we ***@***.*** and @skywalker2012 ) think of almost the same routing algorithm independently at the same time ([1] and [2]). The improvement in the Flexlayer pass from Sabre routing pass would be: Use of dependency graph Small change in the decay weight W so that it depends on the step size from the current layer (e.g. 0.5 for gates in the next layer, 0.25 for gates in the next next layer, etc) Use of bridge gates as well as swap gates (proposed in [3] = extended paper of [1]) I think I should close this PR and open a new PR that extends the Sabre routing pass (should I create a new subclass of Sabre routing pass?). What do you think? @ajavadia I admit the Sabre layout pass, that implements Li's reverse traversal technique, is very cool and useful (That would be the main difference between [1] and [2] as I mentioned in [3]). I know I don't need to touch the layout pass. [1] T. Itoko et al. Quantum circuit compilers using gate commutation rules. In Proceedings of the 24th Asia and South Pacific Design Automation Conference, pp. 191-196 (2019). [2] G. Li, Y. Ding, Y. Xie, Tackling the qubit mapping problem for nisq-era quantum devices, In Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems, ACM, 2019, pp. 1001-1014. [3] T. Itoko et al. Optimization of quantum circuit mapping using gate transformation and commutation. Integration 70 (2020): 43-50. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[mtreinish]

@itoko since this has been stale without update for ~1 year and was initially proposed >2 yrs ago I'm going to close this. But please feel free to reopen this if you have the bandwidth to finish it and update this for current terra.