Add defined phases to the PassManager #5978
Labels
type: enhancement
It's working, but needs polishing
Comments
|
I'm not sure if |
mtreinish
added a commit
to mtreinish/qiskit-core
that referenced
this issue
May 12, 2021
This commit adds a new PassManager subclass, FullPassManager. This class is used to have a PassManager with a defined structure and stages for the normal transpile workflow. The preset pass managers are then updated to be FullPassManager objects they conform to the fixed structure. Having a class with defined phases gives us flexibility in the future for making the transpiler pluggable with external plugins (similar to what's done in PR Qiskit#6124) and also have backend hook points before or after different phases of the transpile. Fixes Qiskit#5978
mergify bot
added a commit
that referenced
this issue
Jun 21, 2022
* Add FullPassManager class for pass manager with defined stages This commit adds a new PassManager subclass, FullPassManager. This class is used to have a PassManager with a defined structure and stages for the normal transpile workflow. The preset pass managers are then updated to be FullPassManager objects they conform to the fixed structure. Having a class with defined phases gives us flexibility in the future for making the transpiler pluggable with external plugins (similar to what's done in PR #6124) and also have backend hook points before or after different phases of the transpile. Fixes #5978 * Add docs * Deduplicate preset passmanager construction * Update docs * Add dedicated scheduling stage to FullPassManager * Add missing new UnitarySynthesis kwargs after rebase * Use basis_translator as default method instead of basis Co-authored-by: Kevin Krsulich <kevin@krsulich.net> * Rename FullPassManager StructuredPassManager * Rename generate_scheduling_post_opt() generate_scheduling() * Fix missing and incorrect arguments * Fix more rebase issues * Fix even more rebase issues * Only run unroll3q on level 0-2 if coupling map is set To preserve the behavior prior to this reorganization this commit makes the Unroll3qorMore pass run if we have a coupling map set. This is because this pass is only needed to be run for these optimization levels so that the layout and routing passes can function (as they only work with 2q gates). If we're not running these passes we shouldn't be unrolling gates. This will fix the last 4 QAOA test failures post the recent rebase as that was failing because we were trying to unroll an unbound 4q hamiltonian gate when weren't before. * Rework StructuredPassManager as a more dynamic StagedPassManager This commit redefines the previous StructuredPassManager class into a more dynamic StagedPassmanager. The StagedPassManager doesn't have fixed hard coded stages anymore but instead lets users define their own stages. It also adds implicit 'pre_' and 'post_' hook points for each listed stage. This lets users dynamically define the stages based on a particular use case. * Fix docs * Update internal pass set on each access This commit updates the api for the StagedPassManager to refresh the internal pass list on each access. This adds a little overhead but with the tradeoff of making in place modifications to a stage's pass manager reflected without needing to manually call an update method. * Rename phases attribute to stages * Fix lint * Explicitly set name in qpy compat tests The rework of the preset passmanager construction changes the import order slightly and the number of circuits constructed in a session prior to the qpy compat deserialization side generating equivalent circuits for comparision has changed. This is causing all the deserialization side numbers to change and the tests are now failing because the circuit names are not equivalent. Since the exact name is a side effect of the import order (based on the number of unnamed circuits created in the session priort) it's not part of what the qpy tests are validating. We're trying to assert that the naem is preserved loading a qpy file across a version boundary. To fix this issues this commit adds an explicit name to the generation for all the circuits to ensure that we have a deterministic name for each circuit. * Apply suggestions from code review Co-authored-by: Luciano Bello <bel@zurich.ibm.com> * Run black * Update type hint * Remove out of date docstring note * Update copyright header date in qiskit/transpiler/preset_passmanagers/common.py Co-authored-by: Luciano Bello <bel@zurich.ibm.com> * Add check for invalid stage names * Add backwards compatibility note * Add docs on using StagedPassManager features with preset passmanagers Co-authored-by: Kevin Krsulich <kevin@krsulich.net> Co-authored-by: Luciano Bello <bel@zurich.ibm.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the expected enhancement?
The typical (and all the preset) pass managers have fixed stages, typically something like:
We should formalize these stages, we can expand the set over time (but probably not remove) and some are obviously optional depending on runtime conditions and options and enable people to compose pass managers by constructing the phases individually and not have to worry about control flow.
This also provides us the option of including hook points for backends to add customization which are backend specific before and after each transpile stage (which is something I'd like to include in #5885 ). For example, if we have a backend with all custom gate definitions our 1q optimization pass will not be able to simplify anything. But, the provider/backend author can write their own pass that runs a custom post optimization loop to do this and we update
transpile().The text was updated successfully, but these errors were encountered: