Skip to content
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

Fix data-flow analysis in control-flow jump/mark #1666

Merged
merged 2 commits into from
Nov 27, 2022

Conversation

jakelishman
Copy link
Member

Summary

During the inlining of control-flow into jump/mark instructions, the data-flow graph was losing information. The tree-like form within QuantumCircuit implicitly creates a basic-block structure, which groups the whole control-flow body into a single block that must be executed atomicly (as seen by the outer circuit). When inlining the body, this is no longer the case, and we have to take more care to ensure that topological iteration through the data-flow graph does not accidentally move jump/mark instructions into incorrect places, nor allow unrelated instructions to appear between jump/mark pairs if they were no originally in that control-flow block.

There are two components here; the former is solved by ensuring the jump/mark instructions span the full data width including clbits, and the latter is solved by placing full circuit width barriers around each control-flow logical component.

Details and comments

Fix #1665.

During the inlining of control-flow into jump/mark instructions, the
data-flow graph was losing information.  The tree-like form within
`QuantumCircuit` implicitly creates a basic-block structure, which
groups the whole control-flow body into a single block that must be
executed atomicly (as seen by the outer circuit).  When inlining the
body, this is no longer the case, and we have to take more care to
ensure that topological iteration through the data-flow graph does not
accidentally move jump/mark instructions into incorrect places, nor
allow unrelated instructions to appear between jump/mark pairs if they
were no originally in that control-flow block.

There are two components here; the former is solved by ensuring the
jump/mark instructions span the full data width including clbits, and
the latter is solved by placing full circuit width barriers around each
control-flow logical component.
@jakelishman jakelishman added the Changelog: Bugfix Include in the Fixed section of the changelog label Nov 22, 2022
Copy link
Collaborator

@hhorii hhorii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

During the inlining of control-flow into jump/mark instructions, the data-flow graph was losing information.

Decomposing an instruction that has a sub-circuit is more complicated than I expected. Thank you for your fix.

When inlining the body, this is no longer the case, and we have to take more care to ensure that topological iteration through the data-flow graph does not accidentally move jump/mark instructions into incorrect places,

This also makes sense to me.

@hhorii hhorii added the stable-backport-potential The issue or PR might be minimal and/or import enough to backport to stable label Nov 25, 2022
@jakelishman
Copy link
Member Author

Yeah, I didn't think about it at first either. It's on my mind now because I'd been discussing with Kevin (@kdk) about better data structures for representing control-flow graphs alongside data-flow ones, and this was one of the major problems we identified.

@jakelishman jakelishman merged commit 4dabb94 into Qiskit:main Nov 27, 2022
@jakelishman jakelishman deleted the fix-topological-control-flow branch November 27, 2022 10:50
hhorii pushed a commit to hhorii/qiskit-aer that referenced this pull request Nov 28, 2022
* Fix data-flow analysis in control-flow jump/mark

During the inlining of control-flow into jump/mark instructions, the
data-flow graph was losing information.  The tree-like form within
`QuantumCircuit` implicitly creates a basic-block structure, which
groups the whole control-flow body into a single block that must be
executed atomicly (as seen by the outer circuit).  When inlining the
body, this is no longer the case, and we have to take more care to
ensure that topological iteration through the data-flow graph does not
accidentally move jump/mark instructions into incorrect places, nor
allow unrelated instructions to appear between jump/mark pairs if they
were no originally in that control-flow block.

There are two components here; the former is solved by ensuring the
jump/mark instructions span the full data width including clbits, and
the latter is solved by placing full circuit width barriers around each
control-flow logical component.

* Fix lint
hhorii pushed a commit to hhorii/qiskit-aer that referenced this pull request Nov 29, 2022
* Fix data-flow analysis in control-flow jump/mark

During the inlining of control-flow into jump/mark instructions, the
data-flow graph was losing information.  The tree-like form within
`QuantumCircuit` implicitly creates a basic-block structure, which
groups the whole control-flow body into a single block that must be
executed atomicly (as seen by the outer circuit).  When inlining the
body, this is no longer the case, and we have to take more care to
ensure that topological iteration through the data-flow graph does not
accidentally move jump/mark instructions into incorrect places, nor
allow unrelated instructions to appear between jump/mark pairs if they
were no originally in that control-flow block.

There are two components here; the former is solved by ensuring the
jump/mark instructions span the full data width including clbits, and
the latter is solved by placing full circuit width barriers around each
control-flow logical component.

* Fix lint
hhorii pushed a commit to hhorii/qiskit-aer that referenced this pull request Nov 29, 2022
* Fix data-flow analysis in control-flow jump/mark

During the inlining of control-flow into jump/mark instructions, the
data-flow graph was losing information.  The tree-like form within
`QuantumCircuit` implicitly creates a basic-block structure, which
groups the whole control-flow body into a single block that must be
executed atomicly (as seen by the outer circuit).  When inlining the
body, this is no longer the case, and we have to take more care to
ensure that topological iteration through the data-flow graph does not
accidentally move jump/mark instructions into incorrect places, nor
allow unrelated instructions to appear between jump/mark pairs if they
were no originally in that control-flow block.

There are two components here; the former is solved by ensuring the
jump/mark instructions span the full data width including clbits, and
the latter is solved by placing full circuit width barriers around each
control-flow logical component.

* Fix lint
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Changelog: Bugfix Include in the Fixed section of the changelog stable-backport-potential The issue or PR might be minimal and/or import enough to backport to stable
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Issue with nested if_test
2 participants