Add ElidePermutations transpiler pass

[mtreinish]

Summary

This commit adds a new transpiler pass ElidePermutations which is a logical optimization pass designed to run prior to layout or any other physical embedding steps in the transpiler pipeline. It traverses the DAG in topological order and when a swap gate is encountered it removes that gate and instead permutes the logical qubits for any subsequent gates in the DAG. This will eliminate any swaps or permutation gates in a circuit not caused by routing.

Additionally, this pass is added to the preset pass manager for optimization level 3, we can consider adding it to other levels too if we think it makes sense (there is little overhead, and almost 0 if there are no swaps).
edit: integrating the pas into the preset pass manager turned out a bit tricky and is delegated to a follow-up PR. in addition, when ElidePermutations is present, we do not need RemoveSwapsBeforeMeasure.

One thing to note is that this pass does not recurse into control flow blocks at all, it treats them as black box operations. So if any control flow blocks contain swap gates those will not be optimized away. This change was made because mapping the permutation outside and inside any control flow block was larger in scope than what the intent for this pass was. That type of work is better suited for the routing passes which already have to reason about this.

Update [by @alexanderivrii ]: This development ended up as a joined effort between @mtreinish, @sbrandhsn and myself. Here are a few additional details. This pass is meant to run on the virtual circuit, before layout and routing. Let $Q$ denote the original virtual circuit. The pass moves all the swaps and permutation gates to the end of the circuit, essentially representing $Q$ as $S - P$, some circuit $S$ followed by a permutation $P$ (of the virtual qubits). The idea is that we can "save" P in the property set's "virtual_permutation_layout" attribute, "forget" about $P$, i.e. transpile $S$, and then incorporate $P$ at the very end by mapping it to a permutation of the physical circuit's qubits and combining (composing) it with the permutation coming from routing. The precise scheme is implemented as an additional FinalizeLayouts transpiler pass that is supposed to run at the very end of the transpilation flow. If $L: V\rightarrow P$ and $F: P\rightarrow P$ respectively denote the "layout permutation" and the "final permutation" for $S$, then for $Q$ the layout permutation is still $S$ while the final permutation is $L^{-1} - P^{-1} - L - F$. One point is that in order to do this update we need to know the layout permutation which is of course not available at the time of ElidePermutations pass. This is why we save $P$ "on the side" and update "final permutation" in FinalizeLayouts. One alternative was to construct $L^{-1} - P^{-1} - L$ in " either SetLayout or ApplyLayout passes, however they do not always run, depending on whether the coupling map is specified or not. So, after a discussion between the three of us, introducing an additional pass FinalizeLayouts made a lot of sense. In addition, it becomes possible to run multiple pre-layout "up to final permutation" passes, such as the StarPreRouting pass followed by ElidePermutations, in which case one should compose the permutations in "virtual_permutation_layout".

This should be rebased on top of #12057 (i.e. the code in operator.py and test_operator.py is not a part of this PR). Having ElidePermutations pass and FinalizeLayouts in separate PRs did not make much sense, so we did not split these into two.

Let me also explain the "strange" update of the final layout above. Suppose that transpiling a virtual circuit $S$ produces the transpiled circuit $T$, initial layout $L$ and final layout $F$. These are related via $$T = L^{-1} - S - L - F.$$
Suppose that we want to transpile $S - P$, $S$ followed by a permutation $P$.
We have:
$$T = L^{-1} - S - L - F = (L^{-1} - S - P - L) - (L^{-1} - P ^{-1} - L - F),$$
which can be interpreted as follows: $T$ is still the resulting transpiled circuit for $S - P$, $L$ is still the initial layout$, and
$(L^{-1} - P ^{-1} - L - F)$ is the new final layout, as claimed.

Details and comments

Co-authored-by: Alexander Ivrii alexi@il.ibm.com

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the the following people are requested to review this:

• @Qiskit/terra-core

[jakelishman]

Oh, good thinking - I'd not have thought about this edge case.

[jakelishman]

Shall we mention that routing will still add required swaps into the circuit but that this strictly enables more opportunity for improvements in routing? That might be too much detail for the note, though.

[mtreinish]

I just realized that I need to update the layout in the property set as part of this pass too, it's breaking 2 tests that are checking unitary equivalence and the from_circuit() method doesn't have enough information to factor in how things get moved around in this pass

[coveralls]

Pull Request Test Coverage Report for Build 4577141342

• 48 of 48 (100.0%) changed or added relevant lines in 7 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.01%) to 85.42%

---

Totals
Change from base Build 4576589370:	0.01%
Covered Lines:	67471
Relevant Lines:	78987

---

💛 - Coveralls

[mtreinish]

This is still failing one test locally for me, but it's a lot closer than it was when I left it ~6 months ago. The failure is in the case where we elide swaps but do not set a layout as part of the transpiler. In that case the final_layout handling doesn't seem to be working correctly and the output unitary with Operator.from_circuit() doesn't match the input circuits. It was working in an earlier iteration of the PR, but when I changed this line: 1d30a65#diff-92d475523dd55dcfa92cfc8772ecddf189dbe7243cce7e020a1e55a876c77e7eL76 from the earlier iterations, to fix the case when an initial layout is set, it started failing when an initial layout isn't set. (I mostly pushed this to save my work)

EDIT: This has been fixed in: 5688293

[mtreinish]

Overall this LGTM, thanks for taking this over the finish line @alexanderivrii! I left a couple of inline suggestions that I'll apply. But from my side this looks good, I'm not able to approve or merge this as I'm the original author of the PR though.

[kevinhartman]

What does the t_ prefix stand for here? For readability, can we write it out?

[mtreinish]

I'm not sure what his intent was with the prefix either, but we can always clean it up in a follow up PR.

[kevinhartman]

From your discussion above @jakelishman , it sounds to me like we ought to consider keeping any new properties private until we i.e. refactor to storing final_permutation.

Thoughts?

[mtreinish]

I'm fine not documenting it explicitly as part of the API although at the end of the day the pass doesn't do much in the absence of a virtual permutation layout. So it's kind of hard to keep it private as part of the pass. I don't think it's adding an extra burden realistically to support it for the remainder of 1.x if we pivot to something else in the future we have to do this already with final_layout.

[jakelishman]

Yeah, part of us not being able to get the final_permutation landed properly for 1.1 is that basically have to support this for the whole 1.x cycle now, but that was priced into the decision - it shouldn't be too painful, and we'd have needed a 2.0 release to make a truly clean break from external routing passes anyway.

[kevinhartman]

Should we also test adding the pass in invalid positions (e.g. after layout), and having both it and FinalizeLayout run twice?

[mtreinish]

I'll add a test for the after layout case. But did you have something in mind for the double case? It's a bit tricky in practice as the pass really isn't designed to be run more than once. The above todo you commented on in: #9523 (comment) is for the case where you have virtual_permutation_layout already set and ensure the pass composes the layouts correctly. We could workaround that by calling FinalizeLayouts before the second execution, but in practice there isn't anything to eliminate a second time unless we insert more swaps after the first time

[mtreinish]

Added the test case for after layout in: f5b6778

[jakelishman]

Fwiw (since I'm assigned) I read through this quickly and there's nothing I immediately wanted to interject beyond what Kevin/Matt already said.

[jakelishman]

Actually, scratch that, I do have a comment - do we think it's definitely better to have FinalizeLayouts as a separate pass that a user could forget to put into a pass manager, or would it be better to shift that logic into PassManager._passmanager_backend, which handles the final_layout in general, so it's not possible to forget?

[mtreinish]

Actually, scratch that, I do have a comment - do we think it's definitely better to have FinalizeLayouts as a separate pass that a user could forget to put into a pass manager, or would it be better to shift that logic into PassManager._passmanager_backend, which handles the final_layout in general, so it's not possible to forget?

FWIW, this is what I did in the original PR. I can adjust back to this, it makes sense to me to always handle this at the pass manager level with the other layout handling.

[mtreinish]

I integrated finalize layouts in the pass manager in: e755bcd

[ElePT]

From the discussions and previous reviews it looks like there are some points that need to be polished in the future, but I think the PR is in a good enough state to move forward, the test coverage is good and the tradeoffs of different design choices have been documented. I only have a couple of minor suggestions based on previous suggestions that weren't applied, other than that, LGTM.

[ElePT]

Suggested change

	optimize away any :class:`~.SwapGate`\s in a circuit by permuting virtual
	optimize away any :class:`~.SwapGate`\s or :class:`~.PermutationGate`\s in a circuit by permuting virtual

[mtreinish]

I think this has been updated already. The current release note text says:

    Added a new optimization transpiler pass, :class:`~.ElidePermutations`,
    which is designed to run prior to the :ref:`layout_stage` and will
    optimize away any :class:`~.SwapGate`\s and
    :class:`~qiskit.circuit.library.PermutationGate`\s
    in a circuit by permuting virtual
    qubits. For example, taking a circuit with :class:`~.SwapGate`\s:

[ElePT]

In case you want to add this info:

Suggested change

	ElideSwaps()(qc).draw("mpl")
	ElideSwaps()(qc).draw("mpl")
	This pass has been added to `optimization_level=3` in `generate_default_pass_manager()`.

[mtreinish]

This one isn't actually the case yet. We're doing this in #12111 , we split out from this PR to test it in isolation (ideally with more time before the release than we actually have now).

[ElePT]

Sloppy reviewing on my side, or maybe I was tricked by GitHub :) Anyways, with those comments addressed LGTM. Thanks for the hard work to all the people involved!!