-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Expand backend specific default methods to cover all stages #16119
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -51,23 +51,26 @@ class BackendV2(Backend, ABC): | |
| something like a ``shots`` field for a backend that runs experiments which | ||
| would contain an int for how many shots to execute. | ||
|
|
||
| A backend object can optionally contain methods named | ||
| ``get_translation_stage_plugin`` and ``get_scheduling_stage_plugin``. If these | ||
| methods are present on a backend object and this object is used for | ||
| A backend object can optionally contain methods named: | ||
| * ``get_init_stage_plugin`` | ||
| * ``get_layout_stage_plugin`` | ||
| * ``get_routing_stage_plugin`` | ||
| * ``get_translation_stage_plugin`` | ||
| * ``get_scheduling_stage_plugin``. | ||
|
Comment on lines
+54
to
+59
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also the docs-build error is a true error and it's complaining that these bullet points are indented by a space, when they shouldn't be indented at all (but you might need a blank line before and after them?). |
||
| If these methods are present on a backend object and this object is used for | ||
| :func:`~.transpile` or :func:`~.generate_preset_pass_manager` the | ||
| transpilation process will default to using the output from those methods | ||
| as the scheduling stage and the translation compilation stage. This | ||
| enables a backend which has custom requirements for compilation to specify a | ||
| stage plugin for these stages to enable custom transformation of | ||
| the circuit to ensure it is runnable on the backend. These hooks are enabled | ||
| by default and should only be used to enable extra compilation steps | ||
| if they are **required** to ensure a circuit is executable on the backend or | ||
| have the expected level of performance. These methods are passed no input | ||
| arguments and are expected to return a ``str`` representing the method name | ||
| which should be a stage plugin (see: :mod:`qiskit.transpiler.preset_passmanagers.plugin` | ||
| for more details on plugins). The typical expected use case is for a backend | ||
| provider to implement a stage plugin for ``translation`` or ``scheduling`` | ||
| that contains the custom compilation passes and then for the hook methods on | ||
| as the respective compilation stage. This enables a backend which has custom | ||
| requirements or bespoke methods for compilation to specify a stage plugin for | ||
| these stages to enable custom compilation of the circuit to ensure it is | ||
| runnable on the backend. These hooks are enabled by default and should only | ||
| be used to enable extra compilation steps if they are **required** to ensure | ||
| a circuit is executable on the backend or have the expected level of performance. | ||
| These methods are passed no input arguments and are expected to return a ``str`` | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This new text adds in the bit about "bespoke methods" in as an additional the "custom requirements" reasons, but that then sounds weird
|
||
| representing the method name which should be a stage plugin (see: | ||
| :mod:`qiskit.transpiler.preset_passmanagers.plugin` for more details on plugins). | ||
| The typical expected use case is for a backend provider to implement a stage | ||
| plugin that contains the custom compilation passes and then for the hook methods on | ||
| the backend object to return the plugin name so that :func:`~.transpile` will | ||
| use it by default when targeting the backend. | ||
|
Comment on lines
+72
to
75
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This isn't "the typical expected use case", I don't think? It's a description of the actual calling signature. It might be clearer by writing out the actual signature (although see the other review comment about just making them overrideable methods). |
||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,11 @@ | ||
| --- | ||
| features_providers: | ||
| - Implementations of the :class:`.BackendV2` abstract class can now define the optional | ||
| methods ``get_init_stage_plugin``, ``get_layout_stage_plugin``, | ||
| ``get_routing_stage_plugin``, and ``get_optimization_stage_plugin`` which can be used | ||
| to specify alternative default plugins to use when invoking the transpiler for that | ||
| backend. When defined these methods should return the name of the plugin | ||
| to use by default when running the corresponding :ref:`transpiler-preset` stages when | ||
| targeting this backend object. These methods work in the same as the existing :class:`.BackendV2` methods | ||
| ``get_translation_stage_plugin`` and ``get_scheduling_stage_plugin`` but for the other | ||
| stages of the :ref:`transpiler-preset`. |
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.
Missing
optimization?