-
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
Backend specific transpiler stages #8329
Comments
mtreinish
added a commit
to mtreinish/qiskit-core
that referenced
this issue
Jul 12, 2022
This commit adds a new transpiler pass to simplify resets after a measurement. This pass when run will replace any reset after a measurement with a conditional X gate. This is because the reset operation on IBM backends is implemented by performing a conditional x gate after a reset. So doing this simplification will improve the fidelity of the circuit because we're removing a duplicate measurement which was implicit in the reset. This pass is based on the marz library: https://github.com/Qiskit-Partners/marz which did the same thing but at the QuantumCircuit level. One note is that this pass is basically specific to IBM backends so it's not added to the preset pass managers. Ideally we'd be able to have the IBM backends run this as part of the init stage or something to do the logical transformation early in the compilation. But right now there is no mechanism to do this (see Qiskit#8329), so for now having the pass and letting users specify it in the pass manager directly is the best option. After Qiskit#8329 is implemented we can look at adding this pass to that hook interface in the ibm provider's backends directly so that they can leverage this optimization whenever they're the compilation target.
mtreinish
added a commit
to mtreinish/qiskit-core
that referenced
this issue
Aug 31, 2022
This commit adds initial support to the transpiler and backend interfaces for backends to specify custom transpiler stages. There are often specific hardware compilation requirements that a general purpose transpiler's preset pass manager can't account for. While we strive to provide interfaces to outline all the hardware constraints via the Target class and general purposes passes to fit and optimize an input circuit to the target backend there are some constraints that aren't easily addressed in a general purpose way. For such cases having an interface for a specific backend which has the necessary context of its own constraints to provide custom compilation steps to integrate into the pipeline is a necessary feature. The two initial examples of this are custom basis gate translation and custom scheduling. This commit adds two new hook point methods for BackendV2 objects, get_post_translation_stage() and get_scheduling_stage(). These allow for backends to specify custom PassManager objects that will run after the translation stage and for the scheduling stage by default when compilation is targetting the backend. This should enable backends with custom hardware specific requirements to influence the compilation process so that any required custom steps to ensure the output circuit is executable. In the future we may add additional hook points in a similar manner to enable backends to assert more hardware-specific compilation where the need arises. Closes Qiskit#8329
mergify bot
added a commit
that referenced
this issue
Sep 2, 2022
* Add ResetAfterMeasureSimplification transpiler pass This commit adds a new transpiler pass to simplify resets after a measurement. This pass when run will replace any reset after a measurement with a conditional X gate. This is because the reset operation on IBM backends is implemented by performing a conditional x gate after a reset. So doing this simplification will improve the fidelity of the circuit because we're removing a duplicate measurement which was implicit in the reset. This pass is based on the marz library: https://github.com/Qiskit-Partners/marz which did the same thing but at the QuantumCircuit level. One note is that this pass is basically specific to IBM backends so it's not added to the preset pass managers. Ideally we'd be able to have the IBM backends run this as part of the init stage or something to do the logical transformation early in the compilation. But right now there is no mechanism to do this (see #8329), so for now having the pass and letting users specify it in the pass manager directly is the best option. After #8329 is implemented we can look at adding this pass to that hook interface in the ibm provider's backends directly so that they can leverage this optimization whenever they're the compilation target. * Fix lint * Tweak wording on release note * Remove stray debug draw() call Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
mergify bot
pushed a commit
that referenced
this issue
Oct 4, 2022
* Add support for custom backend transpiler stages This commit adds initial support to the transpiler and backend interfaces for backends to specify custom transpiler stages. There are often specific hardware compilation requirements that a general purpose transpiler's preset pass manager can't account for. While we strive to provide interfaces to outline all the hardware constraints via the Target class and general purposes passes to fit and optimize an input circuit to the target backend there are some constraints that aren't easily addressed in a general purpose way. For such cases having an interface for a specific backend which has the necessary context of its own constraints to provide custom compilation steps to integrate into the pipeline is a necessary feature. The two initial examples of this are custom basis gate translation and custom scheduling. This commit adds two new hook point methods for BackendV2 objects, get_post_translation_stage() and get_scheduling_stage(). These allow for backends to specify custom PassManager objects that will run after the translation stage and for the scheduling stage by default when compilation is targetting the backend. This should enable backends with custom hardware specific requirements to influence the compilation process so that any required custom steps to ensure the output circuit is executable. In the future we may add additional hook points in a similar manner to enable backends to assert more hardware-specific compilation where the need arises. Closes #8329 * Remove stray optimization level args from pm config * Fix tests * Apply suggestions from code review Co-authored-by: Jake Lishman <[email protected]> * Pivot backend transpiler hook points to leverage plugins Since in qiskit-terra 0.22.0 we're adding a plugin interface for transpiler stages already, the more natural fit for enabling backends to inject custom passes into a pass maanger is via that plugin interface. This commit updates the hook points to return a plugin method name that a backend should use by default. This will provide the same level of flexibility but also export any custom stages as standalone methods that users can call into if they need to and also advertise the custom stage methods along with all other installed methods. * Apply suggestions from code review Co-authored-by: Kevin Krsulich <[email protected]> * Update qiskit/providers/__init__.py Co-authored-by: Kevin Krsulich <[email protected]> * Update release note * Update qiskit/providers/backend.py Co-authored-by: John Lapeyre <[email protected]> * Rename transpile() option and reword doc * Rename hook methods backend_ * Update qiskit/compiler/transpiler.py Co-authored-by: John Lapeyre <[email protected]> Co-authored-by: Jake Lishman <[email protected]> Co-authored-by: Kevin Krsulich <[email protected]> Co-authored-by: John Lapeyre <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What should we add?
Now that we have the
StagedPassManager
class this gives us flexibility in how we can compose and hook into the transpilation pipeline at specific points. The first piece of this is transpiler stage plugins which is being done in #8305 the other piece which is needed is a way for backends to add additional backend specific passes to the compilation pipeline. The idea being some passes are hardware specific and having a mechanism for a backend to provide it's ownPassManager
that will be run at fixed points in the compilation pipeline will enable backend authors to implement these hardware specific passes in a standardized way and when the compilation target is that backend it will run the pass manager at the appropriate point in the compilation.The text was updated successfully, but these errors were encountered: