-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure translation
stage always outputs ISA circuits
#13792
Ensure translation
stage always outputs ISA circuits
#13792
Conversation
One or more of the following people are relevant to this code:
|
Pull Request Test Coverage Report for Build 13168271554Warning: 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.
Details
💛 - Coveralls |
This shifts the responsibility of the `translation` stage slightly to always output ISA circuits. It previously was not 100% required that they did this, at least implicitly because Qiskit's built-in plugins didn't always respect 2q direction. The builtin translation plugins now always respect 2q direction, which removes the need for the `pre_optimization` implicit stage, freeing it up for better user customisation. This (in theory) shouldn't have runtime impacts because the optimisation loop was already having to do this afterwards anyway. For potential plugins that _do_ respect gate direction (like the upcoming `BasisConstructor`), it can be a speedup in the default pipeline, since they won't need to run the gate-direction check any more.
0caf0c9
to
92f30cd
Compare
Now rebased over |
I ran the full benchmark suite, and there (as mostly expected) doesn't seem to be much change from this. There's a small positive improvement in a couple of places of runtime, though I'm not convinced it wasn't just fluctuations on my machine. There's depth improvements in QUEKO, perhaps because in cases where the optimisation loop is entered twice, there's a bit more information available to it? Or maybe it's just because there's the knock-on effect of some changes to the randomisation.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am absolutely in favor of this change, I think it's much cleaner and flexible, and the changes look good! I just left a question for my own understanding of the passes.
# run a little bit of fix up on them. `GateDirection` doesn't guarantee that 1q gates are | ||
# ISA safe after it runs, so we need another run too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to make sure I understood this sentence, is it GateDirection
or CheckGateDirection
that doesn't guarantee that 1q gates are ISA?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's GateDirection
- that's the one that actually inserts gates. CheckGateDirection
just says whether or not we need to run GateDirection
and the subsequent fixer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Summary
This shifts the responsibility of the
translation
stage slightly to always output ISA circuits. It previously was not 100% required that they did this, at least implicitly because Qiskit's built-in plugins didn't always respect 2q direction.The builtin translation plugins now always respect 2q direction, which removes the need for the
pre_optimization
implicit stage, freeing it up for better user customisation.This (in theory) shouldn't have runtime impacts because the optimisation loop was already having to do this afterwards anyway. For potential plugins that do respect gate direction (like the upcoming
BasisConstructor
), it can be a speedup in the default pipeline, since they won't need to run the gate-direction check any more.Details and comments
Built on top of #13620, since it will need to change documentation in that PR.
Fix #13787.