Add target support to basis, optimization, scheduling, and util passes

[mtreinish]

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

[qiskit-bot]

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:

• @Qiskit/terra-core
• @enavarro51
• @nkanazawa1989

[coveralls]

Pull Request Test Coverage Report for Build 3970101828

• 87 of 109 (79.82%) changed or added relevant lines in 16 files are covered.
• 2 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.01%) to 84.924%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/transpiler/passes/calibration/rzx_builder.py	2	3	66.67%
qiskit/transpiler/passes/optimization/echo_rzx_weyl_decomposition.py	2	3	66.67%
qiskit/transpiler/passes/scheduling/base_scheduler.py	2	3	66.67%
qiskit/transpiler/passes/scheduling/padding/dynamical_decoupling.py	4	5	80.0%
qiskit/transpiler/passes/utils/check_cx_direction.py	1	2	50.0%
qiskit/transpiler/passes/optimization/crosstalk_adaptive_schedule.py	2	4	50.0%
qiskit/transpiler/passes/scheduling/dynamical_decoupling.py	1	3	33.33%
qiskit/transpiler/passes/basis/unroller.py	22	28	78.57%
qiskit/transpiler/passes/optimization/optimize_1q_gates.py	25	32	78.13%

Files with Coverage Reduction	New Missed Lines	%
qiskit/transpiler/passes/utils/check_cx_direction.py	1	75.0%
src/vf2_layout.rs	1	86.44%

Totals
Change from base Build 3970100474:	-0.01%
Covered Lines:	66705
Relevant Lines:	78547

---

💛 - Coveralls

[nkanazawa1989]

Alternatively you can store target instead of the legacy instmap if available, or I can do it in follow up.

[mtreinish]

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.

[ajavadia]

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?

[mtreinish]

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).

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)

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 looked at this it's a bug in the Target.durations() method which generates an InstructionDurations object from a Target. Basically the target needs to figured out when we have a fixed angle version of a gate to pass that in the format InstructionDurations expects. Right now it's adding a new name to the durations object for each parameter value. I think it should be fixed in a standalone PR though (which we can do post rc1 for 0.23.0 final) since it's self contained and logically independent from this change. I'll work on this in parallel and push up a PR for it.

[ajavadia]

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.