Skip to content

Simplify Sabre release-valve calculation#15897

Merged
alexanderivrii merged 1 commit intoQiskit:mainfrom
jakelishman:sabre/layers/release-valve
Mar 29, 2026
Merged

Simplify Sabre release-valve calculation#15897
alexanderivrii merged 1 commit intoQiskit:mainfrom
jakelishman:sabre/layers/release-valve

Conversation

@jakelishman
Copy link
Copy Markdown
Member

There is an edge case in release-valve handling where, if the shortest path is a single swap (but the heuristics have been chosen such that it is unselectable normally), it is possible for the release valve to cause two gates to be routed. The previous handling of this path was written in quite a complicated manner, likely to be able to use closest_node by name from its discovery earlier in the release-valve process.

Instead, it is easier to recognise that, given a single swap:

  • the two qubits cannot be part of the same gate, or the gate would have been routable without the swap;
  • the closest_node must touch one of these qubits because of the the Dijkstra search;
  • therefore we can simply add any routable gate that touches either qubit without risk of duplication or forgetting closest_swap.

Summary

Details and comments

This was separated out from #14909 owing to #14909 (comment).

There is an edge case in release-valve handling where, if the shortest
path is a single swap (but the heuristics have been chosen such that it
is unselectable normally), it is possible for the release valve to cause
_two_ gates to be routed.  The previous handling of this path was
written in quite a complicated manner, likely to be able to use
`closest_node` by name from its discovery earlier in the release-valve
process.

Instead, it is easier to recognise that, given a single swap:

* the two qubits cannot be part of the same gate, or the gate would have
  been routable _without_ the swap;
* the `closest_node` must touch one of these qubits because of the
  the Dijkstra search;
* therefore we can simply add any routable gate that touches _either_
  qubit without risk of duplication or forgetting `closest_swap`.
@jakelishman jakelishman added this to the 2.5.0 milestone Mar 29, 2026
@jakelishman jakelishman requested a review from a team as a code owner March 29, 2026 11:11
@jakelishman jakelishman added Changelog: None Do not include in the GitHub Release changelog. mod: transpiler Issues and PRs related to Transpiler labels Mar 29, 2026
@qiskit-bot
Copy link
Copy Markdown
Collaborator

One or more of the following people are relevant to this code:

  • @Qiskit/terra-core

@jakelishman
Copy link
Copy Markdown
Member Author

In rebasing the rest of the chain around this, I discovered more why I'd previously folded this into an earlier commit (without particularly noticing) - the RoutingState::front_layer attribute gets completely removed in #14911. It's fine, though - the new form works easily, and the logical improvement in this PR is still sound.

Copy link
Copy Markdown
Member

@alexanderivrii alexanderivrii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@alexanderivrii alexanderivrii added this pull request to the merge queue Mar 29, 2026
@jakelishman jakelishman changed the title Simply Sabre release-valve calculation Simplify Sabre release-valve calculation Mar 29, 2026
Merged via the queue into Qiskit:main with commit b2d4c87 Mar 29, 2026
27 checks passed
@jakelishman jakelishman deleted the sabre/layers/release-valve branch March 29, 2026 12:14
jakelishman added a commit to jakelishman/qiskit-terra that referenced this pull request Mar 29, 2026
There is an edge case in release-valve handling where, if the shortest
path is a single swap (but the heuristics have been chosen such that it
is unselectable normally), it is possible for the release valve to cause
_two_ gates to be routed.  The previous handling of this path was
written in quite a complicated manner, likely to be able to use
`closest_node` by name from its discovery earlier in the release-valve
process.

Instead, it is easier to recognise that, given a single swap:

* the two qubits cannot be part of the same gate, or the gate would have
  been routable _without_ the swap;
* the `closest_node` must touch one of these qubits because of the
  the Dijkstra search;
* therefore we can simply add any routable gate that touches _either_
  qubit without risk of duplication or forgetting `closest_swap`.
github-merge-queue Bot pushed a commit that referenced this pull request Apr 1, 2026
* Simply Sabre release-valve calculation (#15897)

There is an edge case in release-valve handling where, if the shortest
path is a single swap (but the heuristics have been chosen such that it
is unselectable normally), it is possible for the release valve to cause
_two_ gates to be routed.  The previous handling of this path was
written in quite a complicated manner, likely to be able to use
`closest_node` by name from its discovery earlier in the release-valve
process.

Instead, it is easier to recognise that, given a single swap:

* the two qubits cannot be part of the same gate, or the gate would have
  been routable _without_ the swap;
* the `closest_node` must touch one of these qubits because of the
  the Dijkstra search;
* therefore we can simply add any routable gate that touches _either_
  qubit without risk of duplication or forgetting `closest_swap`.

* Add explicit turbofish typing
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Changelog: None Do not include in the GitHub Release changelog. mod: transpiler Issues and PRs related to Transpiler

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

4 participants