Add control-flow support to GatesInBasis

[jakelishman]

Summary

It's not yet entirely clear how control-flow will be supported through the Target and basis_gates, but for the time being, we just test them as if they will be added like any other instruction. This is unlikely to entirely remain the case as more classical handling is added.

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

[mtreinish]

Thanks for doing this it LGTM, it seems simple and straightforward enough.

[mtreinish]

My thinking on the support was that a Target would need to contain the control flow ops the backend supported. We already require that measurement, reset, delay, and other non gate operations need to be in the target for it to be usable on the backend so I wasn't really treating control flow any differently. TBH, I was less interested in the BackendV1 basis gates approach and haven't thought about it much, although I guess the analogous thing would be to include the suported control flow instructions in the basis gates list.

[coveralls]

Pull Request Test Coverage Report for Build 3163192353

• 16 of 16 (100.0%) changed or added relevant lines in 1 file are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.0009%) to 84.669%

---

Files with Coverage Reduction	New Missed Lines	%
qiskit/extensions/quantum_initializer/squ.py	2	79.78%

Totals
Change from base Build 3163192223:	-0.0009%
Covered Lines:	61630
Relevant Lines:	72789

---

💛 - Coveralls

[jakelishman]

At the moment there's an issue that control-flow operations are naturally variadic in qubit count, but even Target.add_instruction(ForLoopOp(...), {None: None}) still imposes a constraint on Target.instruction_supported that the number of qubits match. Since you can only hold one ForLoopOp instruction for the for_loop name, you can't really represent that variadicity.

[jakelishman]

For V1, just throwing it in the basis gates will work for now. I suspect we'll probably need to look towards a V2.5 / backwards-compatible V3 as more classical control is added, but it does depend strongly on how much classical processing information we want to pass from backends to Terra.

[mtreinish]

Well we can evolve the target interface independently of backend too. That's part of why I made them separate objects (although far from the primary reason). But that's something we'll have to look at for 0.23.0 I guess because it's a general issue for any variable width operation (thinking a global MS gate on ions would have the same problem). I'll open an issue to track this for 0.23.0.

[jakelishman]

Oh, good forward thinking with the backend/target split, then - I hadn't fully considered that at all. Yeah, that does give us rather more freedom.