Skip to content

Adding debug-info tracking through Qiskit compilation - #80

Open
Jake Lishman (jakelishman) wants to merge 4 commits into
Qiskit:masterfrom
jakelishman:qiskit-debug-info
Open

Adding debug-info tracking through Qiskit compilation#80
Jake Lishman (jakelishman) wants to merge 4 commits into
Qiskit:masterfrom
jakelishman:qiskit-debug-info

Conversation

@jakelishman

Copy link
Copy Markdown
Member

This is a design proposal and approximate implementation plan for adding the concept of "debugging information" into the existing Qiskit circuit IRs, with the follow-on intention of this being included in a subsequent IR framework within Qiskit.

The immediate things this is supposed to enable (with additional tooling built on top of it):

  • post-compilation visualisations / data analysis of the effects of individual passes
  • an abstraction layer to allow a resource-estimation framework to hook into compilation, without requiring it to be compile-time integrated

The debug information system doesn't solve these alone, but it provides the abstraction such that the extra tooling can be built on top. The abstraction is intended to be entirely uncoupled from DAGCircuit/QuantumCircuit, such that the same DebugContext object will be usable in a new IR framework, and it'll just by the dynamic/polymorphic SourceContext/Creator implementations that will be new.

For a follow-on example, I expect it will be less than one day's work, once the DebugContext object is implemented within Qiskit, to write a simple exporter of it to some re-usable hierarchical format that can be fed into an existing flamegraph-SVG generator to make a first-pass basic visualisation. (Fleshing out a full visualisation and designing nicer user interfaces for configuration of it, etc, would be more work that we may or may not choose to do.)

@ihincks

Copy link
Copy Markdown
Contributor

I'm wondering what can or should be done about nested pass managers. That is, for example, a Pass that itself owns an instance of a PassManager that it invokes when acting. I believe we already use this pattern in a couple of spots, and I expect its usage will increase with QuantumProgram: A pass manager that wants to act as QuantumProgram->QuantumProgram, but as a sub-step, for example, cause all circuits in all shot loops to be ISA compliant according to the usual pass manager.

Julien Gacon (@Cryoris) is thinking about multi-IR infrastructure for our compiler infrastructure, so it seems like a good time to consider this.

@Cryoris

Copy link
Copy Markdown
Contributor

I'll open the RFC soon (🤞🏻) so we can discuss the PM more there! Generally I was thinking of allowing nesting by composing tasks rather than pass managers to avoid having multiple executing instances. I'll make sure to mention this in the doc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants