Qiskit
Add VF2PostLayout to the C Transpiler pipeline
Summary
This commit adds the vf2 post layout transpiler pass to the rust transpile() function used by qk_transpile() in C. This was not included originally because there wasn't a path to running vf2postlayout from rust before but since this has been added now we can run the pass as part of the C transpilation.
One detail that was added as part of this the function for filling out a post layout with idle physical qubits was missing from the vf2 post implementation in rust since for the Python pass it was done Python side still. This was added as a standalone function for rust since we need it in rust, but the Python implementation still makes sense for the python side.
Details and comments
This PR is based on top of: https://github.com/Qiskit/qiskit/pull/14863 and will need to be rebased once that merges. In the meantime you can view the contents of just this PR by looking at the HEAD commit: https://github.com/Qiskit/qiskit/commit/4eda52604b4ee8acb8114a68b9985f397b3a0dc3
One or more of the following people are relevant to this code:
-
@Qiskit/terra-core
Pull Request Test Coverage Report for Build 20079581233
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
- For more information on this, see Tracking coverage changes with pull request builds.
- To avoid this issue with future PRs, see these Recommended CI Configurations.
- For a quick fix, rebase this PR at GitHub. Your next report should be accurate.
Details
- 84 of 86 (97.67%) changed or added relevant lines in 3 files are covered.
- 13 unchanged lines in 5 files lost coverage.
- Overall coverage increased (+0.02%) to 88.334%
| Changes Missing Coverage | Covered Lines | Changed/Added Lines | % |
|---|---|---|---|
| crates/transpiler/src/transpiler.rs | 64 | 66 | 96.97% |
| <!-- | Total: | 84 | 86 |
| Files with Coverage Reduction | New Missed Lines | % |
|---|---|---|
| crates/circuit/src/parameter/parameter_expression.rs | 1 | 82.3% |
| crates/transpiler/src/passes/unitary_synthesis.rs | 1 | 93.32% |
| crates/transpiler/src/transpiler.rs | 2 | 93.7% |
| crates/qasm2/src/lex.rs | 4 | 91.77% |
| qiskit/transpiler/preset_passmanagers/common.py | 5 | 84.69% |
| <!-- | Total: | 13 |
| Totals | |
|---|---|
| Change from base Build 20059722453: | 0.02% |
| Covered Lines: | 96273 |
| Relevant Lines: | 108988 |
💛 - Coveralls
Either I'm not understand the flow correctly or there's some information not being passed properly: I would expect the layouting stage to return the layout + source and then both these being consumed by routing, optimization and following passes. Patching default values seems like information might get lost. I would rather defer this to 2.4 and ensure we're getting this flow right before introducing potential bugs
Either I'm not understand the flow correctly or there's some information not being passed properly: I would expect the layouting stage to return the layout + source and then both these being consumed by routing, optimization and following passes. Patching default values seems like information might get lost. I would rather defer this to 2.4 and ensure we're getting this flow right before introducing potential bugs
The missing piece is the todo in the optimization stage which needs to be replaced with a mutable reference to the transpile layout (which is why it was a todo). The layout source isn't metadata needed after routing though it's just used to control whether we need to run vf2post in routing or not. The reason to do this in 2.3 though is this requires changes to the signatures on the stage functions in the c API which haven't been released yet. After 2.3.0rc1 this requires a breaking change to update the signatures to account for the layout in the optimization stage and whether we need to run vf2post in routing.
I'm with Julien that I think we're better deferring the PR at this point - the RC release is supposed to be today, and we're already late on CF (and then Target as a knock-on effect from me).
The signatures in these functions won't be the final ones anyway (since we're pretty sure we're going to need to pass a more complete "state" object), so I don't think it's the end of the world if they're imperfect in this release. It would technically a breaking change, but it's within our policy for the C API and unlike things to do with Target or the circuits, we're not really expecting any major downstream projects to be dependent on these stage functions yet anyway, so I don't think the impact would be large.
