-
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
Add target support to basis, optimization, scheduling, and util passes #9343
Conversation
This commit updates all the basis, optimization, and util passes which leverage hardware constraints to have a new optional keyword argument, target, to specify a Target object for modelling the constraints of the target backend. This option will superscede any other specified arguments for backend constraints. With this and Qiskit#9263 all the passes except for the scheduling passes which take in backend constraints are made target aware. Making all the passes target aware is the first step towards making all backend constraints for the transpiler used the Target internally (see Qiskit#9256). Once all passes that take hardware constraints parameters as an input are updated to have a target we can start internally using the Target only for all preset pass manager construction and start the long process of deprecating the legacy interface in these passes.
Thank you for opening a new pull request. Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone. One or more of the the following people are requested to review this:
|
@@ -90,6 +95,8 @@ def __init__( | |||
|
|||
self._inst_map = instruction_schedule_map | |||
self._verbose = verbose | |||
if target: | |||
self._inst_map = target.instruction_schedule_map() |
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.
Alternatively you can store target instead of the legacy instmap if available, or I can do it in follow up.
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.
Yeah, I was thinking we could optimize some of these passes to work natively with a target in the future. For this PR just having the target option is sufficient I think because my goal for 0.24.0 is to update all the preset pass managers to work solely with a target so we can start to unify the transpiler passes to only need a target in the future.
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 think this PR is fine, perhaps some tests to flex the new target
paths would be good (or modify some of the old tests to run with target instead of say basis_gates).
However testing this in my own environment I found that target.durations()
does not handle the case of different params having different durations. For example RX(pi/2) and RX(pi/6) can have different durations in the target, but the conversion just makes an InstructionDurations
object with entries rx_90 and rx_30, which masks that these are actually the same operation, just different params.
The InstructionDurations
class is actually able to represent the case of different params having different durations, after #7321. So can you make a test in this PR that is able to for example schedule a circuit containing RX(pi/2) and RX(pi/6) using the ALAPSchedule
pass on a Target that specifies the durations of those instructions?
I've added some test coverage in: b1e2024 and 5fed919 I can add more if you want more in depth coverage (or if I missed any passes)
I looked at this it's a bug in the |
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.
I agree with a standalone PR to resolve the issue in target.durations()
and then adding a test to make sure we can schedule on targets with parameterized gates of different durations.
In the recently merged Qiskit#9343 support for using the Target directly was added to the RZXCalibrartionBuilder family of passes. However, test coverage in that PR was omitted by mistake for that pass (other passes in the PR were covered). There was a bug in the code change introduced in that PR which caused an error on initialization if a target were specified without an InstructionScheduleMap (which was the intent of the new target kwarg). This commit fixes the logic bug in the pass and adds test coverage to ensure specifying only a target continues to work moving forward.
In the recently merged Qiskit#9343 support for using the Target directly was added to the RZXCalibrartionBuilder family of passes. However, test coverage in that PR was omitted by mistake for that pass (other passes in the PR were covered). There was a bug in the code change introduced in that PR which caused an error on initialization if a target were specified without an InstructionScheduleMap (which was the intent of the new target kwarg). This commit fixes the logic bug in the pass and adds test coverage to ensure specifying only a target continues to work moving forward.
In the recently merged #9343 support for using the Target directly was added to the RZXCalibrartionBuilder family of passes. However, test coverage in that PR was omitted by mistake for that pass (other passes in the PR were covered). There was a bug in the code change introduced in that PR which caused an error on initialization if a target were specified without an InstructionScheduleMap (which was the intent of the new target kwarg). This commit fixes the logic bug in the pass and adds test coverage to ensure specifying only a target continues to work moving forward. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Summary
This commit updates all the basis, optimization, and util passes which leverage hardware constraints to have a new optional keyword argument, target, to specify a Target object for modelling the constraints of the target backend. This option will supersede any other specified arguments for backend constraints.
With this and #9263 all the passes which take in backend constraints are made target aware. Making all the passes target aware is the first step towards making all backend constraints for the transpiler used the Target internally (see #9256). Once all passes that take hardware constraints parameters as an input are updated to have a target we can start internally using the Target only for all preset pass manager construction and start the long process of deprecating the legacy interface in these passes.
Details and comments