Adding debug-info tracking through Qiskit compilation - #80
Adding debug-info tracking through Qiskit compilation#80Jake Lishman (jakelishman) wants to merge 4 commits into
Conversation
341e34f to
c9edf79
Compare
|
I'm wondering what can or should be done about nested pass managers. That is, for example, a Julien Gacon (@Cryoris) is thinking about multi-IR infrastructure for our compiler infrastructure, so it seems like a good time to consider this. |
|
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. |
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):
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 sameDebugContextobject will be usable in a new IR framework, and it'll just by the dynamic/polymorphicSourceContext/Creatorimplementations that will be new.For a follow-on example, I expect it will be less than one day's work, once the
DebugContextobject 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.)