-
Notifications
You must be signed in to change notification settings - Fork 361
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
Fix data-flow analysis in control-flow jump/mark #1666
Conversation
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.
There was a problem hiding this 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.
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. |
* 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
* 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
* 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
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.